आप 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 को कई स्वतंत्र, समानांतर 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 हो जाए, आप बिना votes खोए अंतिम committed offset से फिर से process करते हैं।

## 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 हर एक-दो सेकंड में compute करता है। Redis में यह बस N `INCR` keys है; DynamoDB में, N partition keys।

## One-vote dedup

"प्रति यूज़र एक vote" को एक idempotency key से लागू करें: `SADD voted:{pollId} {userId}` (या एक conditional put)। अगर यूज़र पहले से मौजूद है, increment करने से पहले event drop करें। यह consumer में करें, client में नहीं — clients झूठ बोलते और retry करते हैं।

## इंटरव्यू का नज़रिया

Interviewer परख रहा है कि क्या आप **single-hot-key समस्या** पहचानते हैं और "अधिक DB replicas जोड़ें" के बजाय buffering + sharding की ओर बढ़ते हैं (replicas reads को scale करती हैं, इस write को नहीं)। अच्छा: "एक queue और एक cache इस्तेमाल करें।" बढ़िया: आप **eventual-consistency trade-off** नाम लेते हैं — live संख्या वास्तविकता से एक सेकंड पीछे रहती है — और तर्क देते हैं कि यह एक vote count के लिए ठीक है पर अंतिम certified परिणाम के लिए *नहीं*, जिसे आप poll बंद होने के बाद authoritatively फिर से compute करते हैं।

**आम जाल:** "accuracy" के लिए प्रति vote एक database transaction इस्तेमाल करना। इस scale पर यही वह चीज़ है जो पिघल जाती है।

## ट्रेड-ऑफ़ और failure modes

- **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

इंटरव्यू का नज़रिया

ट्रेड-ऑफ़ और failure modes

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