10 నిమిషాల్లో 5M votes ను scale వద్ద మీరు ఎలా handle చేస్తారు?

Question

IT Interview Practice · Accepted Answer

ప్రతి vote ను నేరుగా ఒక database row కి వ్రాయవద్దు — **writes ను buffer చేయండి, counters ను shard చేయండి, మరియు eventual tally ను అంగీకరించండి**. 10 నిమిషాల్లో 5M votes అంటే సగటున ~8,300 votes/sec, spikes చాలా ఎక్కువ (ఒక live TV moment దానిని 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; spike సమయంలో consumers వెనుకబడితే, events DB ను overwhelm చేయడానికి బదులు log లో వేచి ఉంటాయి. Kafka **replay** ను కూడా ఇస్తుంది — ఒక consumer crash అయితే, votes కోల్పోకుండా చివరి committed offset నుండి reprocess చేస్తారు.

## 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 అంతటా విస్తరించి parallel గా నడుస్తాయి. ప్రదర్శించబడే 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 చేయండి. దీన్ని client లో కాదు, consumer లో చేయండి — clients అబద్ధం చెప్పి retry చేస్తాయి.

## ఇంటర్వ్యూ దృక్కోణం

మీరు **single-hot-key problem** ను గుర్తించి "add more DB replicas" కంటే buffering + sharding కోసం చేరుకుంటారా అని ఇంటర్వ్యూయర్ పరిశీలిస్తారు (replicas reads ను scale చేస్తాయి, ఈ write ను కాదు). మంచిది: "queue మరియు cache వాడండి." గొప్పది: మీరు **eventual-consistency trade-off** ను పేర్కొంటారు — live number వాస్తవికత కంటే ఒక సెకను వెనుకబడుతుంది — మరియు అది ఒక vote count కి పర్వాలేదు కానీ poll ముగిసిన తర్వాత మీరు authoritatively recompute చేసే *final certified result* కి కాదు అని వాదిస్తారు.

**సాధారణ ఉచ్చు:** "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 typical.
- **Fairness/fraud:** ఒక్కో IP/device కి rate-limit; one-vote SET మీ integrity boundary. దానిని కోల్పోవడం crash కాదు, ballot stuffing — బహుశా అధ్వాన్నం.

writes ను ఎందుకు buffer చేయాలి

Sharded counters hotspot ను చంపుతాయి

One-vote dedup

ఇంటర్వ్యూ దృక్కోణం

ట్రేడ్-ఆఫ్‌లు & వైఫల్య మోడ్‌లు

సంబంధిత ప్రశ్నలు