10 मिनेटमा 50 लाख vote scale मा कसरी सम्हाल्नुहुन्छ?

Question

IT Interview Practice · Accepted Answer

प्रत्येक vote सिधै database row मा नलेख्नुहोस् — **write buffer गर्नुहोस्, counter shard गर्नुहोस्, र eventual tally स्वीकार गर्नुहोस्**। 10 मिनेटमा 50 लाख vote भनेको औसत ~8,300 vote/sec हो, जसमा spike धेरै उच्च हुन्छ (live TV क्षण ले त्यसलाई 10x गर्न सक्छ)। चाल भनेको एउटा hot single-row update लाई धेरै स्वतन्त्र, समानान्तर increment मा परिणत गर्नु हो।

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

## किन write हरू buffer गर्ने

**Kafka** जस्तो queue ले ingestion लाई tallying बाट decouple गर्छ। client write एउटा सस्तो append हो; spike मा consumer पछि परे, event हरू DB लाई अत्यधिक भार दिनुको सट्टा log मा पर्खन्छन्। Kafka ले **replay** पनि दिन्छ — consumer crash भए, तपाईं अन्तिम committed offset बाट पुनः-प्रक्रिया गर्नुहुन्छ, vote नगुमाई।

## Sharded counter ले hotspot मार्छ

"Option A" का लागि प्रत्येक vote ले `UPDATE counter SET n=n+1 WHERE id='A'` गर्‍यो भने, त्यो एउटै row lock-contention bottleneck बन्छ — हजारौं transaction एउटा row मा serialize हुन्छन्। बरु, प्रत्येक option लाई **N shard row** (`A:0 … A:63`) मा विभाजन गर्नुहोस्। प्रत्येक increment एउटा random shard हान्छ, त्यसैले write N row मा फैलिन्छन् र समानान्तर चल्छन्। देखाइने total `SUM(shards)` हो, aggregator ले हरेक एक-दुई second मा गणना गर्छ। Redis मा यो केवल N `INCR` key हो; DynamoDB मा, N partition key।

## One-vote dedup

idempotency key ले "प्रति प्रयोगकर्ता एक vote" लागू गर्नुहोस्: `SADD voted:{pollId} {userId}` (वा conditional put)। प्रयोगकर्ता पहिले नै अवस्थित छ भने, increment अघि event drop गर्नुहोस्। यो client मा होइन, consumer मा गर्नुहोस् — client ले झूट बोल्छन् र retry गर्छन्।

## अन्तर्वार्ता दृष्टिकोण

अन्तर्वार्ताकारले तपाईंले **single-hot-key समस्या** चिन्नुहुन्छ र "अझ बढी DB replica थप" (replica ले read scale गर्छ, यो write होइन) को सट्टा buffering + sharding तिर पुग्नुहुन्छ कि भनेर probe गर्दै हुन्छन्। राम्रो: "queue र cache प्रयोग गर।" उत्कृष्ट: तपाईंले **eventual-consistency ट्रेड-अफ** नाम दिनुहुन्छ — live संख्या वास्तविकता भन्दा एक second पछि पर्छ — र त्यो vote count का लागि ठीक छ तर poll बन्द भएपछि authoritative रूपमा पुनः-गणना गरिने *अन्तिम प्रमाणित नतिजा* का लागि होइन भनेर तर्क गर्नुहुन्छ।

**साधारण जाल:** "शुद्धता" का लागि प्रति vote database transaction प्रयोग गर्नु। यो scale मा त्यही नै पग्लन्छ।

## ट्रेड-अफ र failure mode

- **Eventual tally:** shard sum पछि पर्छ; live counter का लागि स्वीकार्य, बन्द हुँदा reconcile गर्नुहोस्।
- **At-least-once delivery:** Kafka ले redeliver गर्न सक्छ — dedup ले increment idempotent बनाउँछ, नत्र तपाईं double-count गर्नुहुन्छ।
- **Hot shard skew:** धेरै थोरै shard भए तपाईं अझै contend गर्नुहुन्छ; धेरै धेरै भए sum गर्न महँगो हुन्छ। 32–128 shard सामान्य हो।
- **निष्पक्षता/छल:** प्रति IP/device rate-limit गर्नुहोस्; one-vote SET तपाईंको integrity सीमा हो। यो गुमाउनु भनेको crash होइन, ballot stuffing हो — तर्कसंगत रूपमा अझ नराम्रो।

किन write हरू buffer गर्ने

Sharded counter ले hotspot मार्छ

One-vote dedup

अन्तर्वार्ता दृष्टिकोण

ट्रेड-अफ र failure mode

सम्बन्धित प्रश्नहरू