10 मिनिटांत 50 लाख votes scale वर तुम्ही कसे हाताळाल?

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 ला अनेक स्वतंत्र, समांतर 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 आहे; spike दरम्यान consumers मागे पडले, तर events DB ला भारून टाकण्याऐवजी log मध्ये थांबतात. Kafka **replay** देखील देते — consumer crash झाल्यास, तुम्ही शेवटच्या committed offset पासून पुन्हा process करता आणि votes गमावत नाही.

## Sharded counters hotspot मारतात

जर "Option A" साठी प्रत्येक vote `UPDATE counter SET n=n+1 WHERE id='A'` करते, तर तीच row एक lock-contention bottleneck बनते — हजारो transactions एका row वर serialize होतात. त्याऐवजी, प्रत्येक option ला **N shard rows** (`A:0 … A:63`) मध्ये विभागा. प्रत्येक increment एका random shard ला धडकते, त्यामुळे writes N rows मध्ये पसरतात आणि समांतर चालतात. दाखवलेले total `SUM(shards)` आहे, जे aggregator दर एक-दोन सेकंदांनी मोजतो. Redis मध्ये हे फक्त N `INCR` keys आहेत; DynamoDB मध्ये, N partition keys.

## One-vote dedup

एका idempotency key ने "प्रति युजर एक vote" लागू करा: `SADD voted:{pollId} {userId}` (किंवा एक conditional put). जर युजर आधीच अस्तित्वात असेल, तर increment करण्याआधी event टाका. हे consumer मध्ये करा, client मध्ये नाही — clients खोटे बोलतात आणि retry करतात.

## मुलाखतीचा दृष्टिकोन

मुलाखत घेणारा तुम्ही **single-hot-key problem** ओळखता का आणि "अधिक DB replicas जोडा" ऐवजी buffering + sharding कडे वळता का हे तपासतो (replicas reads scale करतात, हे write नव्हे). चांगले: "queue आणि cache वापरा." उत्तम: तुम्ही **eventual-consistency तडजोड** नावाने सांगता — live संख्या वास्तवाच्या एक सेकंद मागे राहते — आणि युक्तिवाद करता की vote count साठी ते ठीक आहे, पण अंतिम certified निकालासाठी *नाही*, जो तुम्ही poll बंद झाल्यावर authoritatively पुन्हा मोजता.

**सामान्य सापळा:** "accuracy" साठी प्रति vote एक database transaction वापरणे. या scale वर तीच गोष्ट वितळते.

## तडजोडी आणि अपयश

- **Eventual tally:** shard sums मागे राहतात; live counter साठी स्वीकार्य, बंद झाल्यावर reconcile करा.
- **At-least-once delivery:** Kafka पुन्हा deliver करू शकते — dedup increments idempotent करते, अन्यथा तुम्ही दोनदा मोजता.
- **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

मुलाखतीचा दृष्टिकोन

तडजोडी आणि अपयश

संबंधित प्रश्न