ਤੁਸੀਂ scale ਉੱਤੇ 10 ਮਿੰਟਾਂ ਵਿੱਚ 50 ਲੱਖ votes ਕਿਵੇਂ ਸੰਭਾਲਦੇ ਹੋ?

Question

IT Interview Practice · Accepted Answer

ਹਰ vote ਨੂੰ ਸਿੱਧਾ ਕਿਸੇ database row ਵਿੱਚ ਨਾ ਲਿਖੋ — **writes ਨੂੰ buffer ਕਰੋ, counters ਨੂੰ shard ਕਰੋ, ਅਤੇ eventual tally ਸਵੀਕਾਰ ਕਰੋ**। 10 ਮਿੰਟਾਂ ਵਿੱਚ 50 ਲੱਖ votes ਔਸਤਨ ~8,300 votes/sec ਹੈ, ਅਤੇ spikes ਬਹੁਤ ਜ਼ਿਆਦਾ (ਇੱਕ live TV ਪਲ ਇਸਨੂੰ 10x ਕਰ ਸਕਦਾ ਹੈ)। ਤਰਕੀਬ ਇਹ ਹੈ ਕਿ ਇੱਕ hot single-row update ਨੂੰ ਬਹੁਤ ਸਾਰੇ ਸੁਤੰਤਰ, parallel increments ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ ਜਾਵੇ।

```text
Client ─▶ Edge/API ─▶ Kafka (vote events) ─▶ Consumers ─┬─▶ Dedup store (SET one-vote)
                        (durable buffer)                 └─▶ Sharded counters (INCR N shards)
                                                                     │
Redis/Aggregator ◀── periodic sum of shards ──────────────────────┘
      │
      └─▶ Read replica / CDN cache ─▶ Live tally to clients
```

## writes ਨੂੰ buffer ਕਿਉਂ ਕਰੀਏ

**Kafka** ਵਰਗੀ ਇੱਕ queue ingestion ਨੂੰ tallying ਤੋਂ decouple ਕਰਦੀ ਹੈ। client write ਇੱਕ ਸਸਤਾ append ਹੈ; ਜੇ consumers ਕਿਸੇ spike ਦੌਰਾਨ ਪਿੱਛੇ ਰਹਿ ਜਾਣ, events DB ਨੂੰ overwhelm ਕਰਨ ਦੀ ਬਜਾਏ log ਵਿੱਚ ਇੰਤਜ਼ਾਰ ਕਰਦੇ ਹਨ। Kafka **replay** ਵੀ ਦਿੰਦੀ ਹੈ — ਜੇ ਇੱਕ consumer crash ਹੋ ਜਾਵੇ, ਤੁਸੀਂ ਆਖਰੀ committed offset ਤੋਂ votes ਗੁਆਏ ਬਿਨਾਂ reprocess ਕਰਦੇ ਹੋ।

## Sharded counters hotspot ਖਤਮ ਕਰਦੇ ਹਨ

ਜੇ "Option A" ਲਈ ਹਰ vote `UPDATE counter SET n=n+1 WHERE id='A'` ਕਰੇ, ਤਾਂ ਓਹ single row ਇੱਕ lock-contention bottleneck ਬਣ ਜਾਂਦੀ ਹੈ — ਹਜ਼ਾਰਾਂ transactions ਇੱਕ row ਉੱਤੇ serialize ਹੁੰਦੇ ਹਨ। ਇਸ ਦੀ ਬਜਾਏ, ਹਰ option ਨੂੰ **N shard rows** (`A:0 … A:63`) ਵਿੱਚ ਵੰਡੋ। ਹਰ increment ਇੱਕ random shard ਨੂੰ hit ਕਰਦਾ ਹੈ, ਇਸ ਲਈ writes N rows ਵਿੱਚ ਫੈਲਦੇ ਹਨ ਅਤੇ parallel ਚੱਲਦੇ ਹਨ। ਵਿਖਾਇਆ ਗਿਆ total `SUM(shards)` ਹੈ, ਜੋ ਇੱਕ aggregator ਹਰ ਸਕਿੰਟ ਜਾਂ ਦੋ ਵਿੱਚ compute ਕਰਦਾ ਹੈ। Redis ਵਿੱਚ ਇਹ ਬਸ N `INCR` keys ਹਨ; DynamoDB ਵਿੱਚ, N partition keys।

## One-vote dedup

"ਹਰ user ਲਈ ਇੱਕ vote" ਨੂੰ ਇੱਕ idempotency key ਨਾਲ ਲਾਗੂ ਕਰੋ: `SADD voted:{pollId} {userId}` (ਜਾਂ ਇੱਕ conditional put)। ਜੇ user ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਹੈ, ਤਾਂ incrementing ਤੋਂ ਪਹਿਲਾਂ event drop ਕਰੋ। ਇਹ consumer ਵਿੱਚ ਕਰੋ, client ਵਿੱਚ ਨਹੀਂ — clients ਝੂਠ ਬੋਲਦੇ ਹਨ ਅਤੇ retry ਕਰਦੇ ਹਨ।

## ਇੰਟਰਵਿਊ ਦਾ ਨਜ਼ਰੀਆ

ਇੰਟਰਵਿਊਅਰ ਪਰਖ ਰਿਹਾ ਹੈ ਕਿ ਕੀ ਤੁਸੀਂ **single-hot-key problem** ਪਛਾਣਦੇ ਹੋ ਅਤੇ "ਹੋਰ DB replicas ਜੋੜੋ" ਦੀ ਬਜਾਏ buffering + sharding ਵੱਲ ਹੱਥ ਵਧਾਉਂਦੇ ਹੋ (replicas reads scale ਕਰਦੇ ਹਨ, ਇਹ write ਨਹੀਂ)। ਵਧੀਆ: "ਇੱਕ queue ਅਤੇ ਇੱਕ cache ਵਰਤੋ।" ਸ਼ਾਨਦਾਰ: ਤੁਸੀਂ **eventual-consistency trade-off** ਦਾ ਨਾਂ ਲੈਂਦੇ ਹੋ — live number ਹਕੀਕਤ ਤੋਂ ਇੱਕ ਸਕਿੰਟ ਪਿੱਛੇ ਰਹਿੰਦਾ ਹੈ — ਅਤੇ ਦਲੀਲ ਦਿੰਦੇ ਹੋ ਕਿ ਇਹ ਇੱਕ vote count ਲਈ ਠੀਕ ਹੈ ਪਰ final certified result ਲਈ *ਨਹੀਂ*, ਜਿਸਨੂੰ ਤੁਸੀਂ poll ਬੰਦ ਹੋਣ ਬਾਅਦ authoritatively ਦੁਬਾਰਾ compute ਕਰਦੇ ਹੋ।

**ਆਮ ਫੰਦਾ:** "accuracy" ਲਈ ਹਰ vote ਲਈ ਇੱਕ database transaction ਵਰਤਣਾ। ਇਸ scale ਉੱਤੇ ਇਹੀ ਓਹ ਚੀਜ਼ ਹੈ ਜੋ ਪਿਘਲ ਜਾਂਦੀ ਹੈ।

## ਟ੍ਰੇਡ-ਆਫ ਅਤੇ ਫੇਲੀਅਰ ਮੋਡ

- **Eventual tally:** shard sums ਪਿੱਛੇ ਰਹਿੰਦੇ ਹਨ; ਇੱਕ live counter ਲਈ ਮਨਜ਼ੂਰ, close ਉੱਤੇ reconcile ਕਰੋ।
- **At-least-once delivery:** Kafka redeliver ਕਰ ਸਕਦੀ ਹੈ — dedup increments ਨੂੰ idempotent ਬਣਾਉਂਦਾ ਹੈ, ਨਹੀਂ ਤਾਂ ਤੁਸੀਂ double-count ਕਰੋਗੇ।
- **Hot shard skew:** ਬਹੁਤ ਘੱਟ shards ਅਤੇ ਤੁਸੀਂ ਫਿਰ ਵੀ contend ਕਰੋਗੇ; ਬਹੁਤ ਜ਼ਿਆਦਾ ਅਤੇ summing ਮਹਿੰਗੀ ਹੋ ਜਾਂਦੀ ਹੈ। 32–128 shards ਆਮ ਹਨ।
- **Fairness/fraud:** ਹਰ IP/device ਲਈ rate-limit ਕਰੋ; one-vote SET ਤੁਹਾਡੀ integrity boundary ਹੈ। ਇਸਨੂੰ ਗੁਆਉਣ ਦਾ ਮਤਲਬ ਹੈ ballot stuffing, crash ਨਹੀਂ — ਸ਼ਾਇਦ ਹੋਰ ਵੀ ਮਾੜਾ।

writes ਨੂੰ buffer ਕਿਉਂ ਕਰੀਏ

Sharded counters hotspot ਖਤਮ ਕਰਦੇ ਹਨ

One-vote dedup

ਇੰਟਰਵਿਊ ਦਾ ਨਜ਼ਰੀਆ

ਟ੍ਰੇਡ-ਆਫ ਅਤੇ ਫੇਲੀਅਰ ਮੋਡ

ਸੰਬੰਧਿਤ ਸਵਾਲ