તમે 10 મિનિટમાં 5M votes ને scale પર કેવી રીતે સંભાળશો?

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`) માં split કરો. દરેક increment એક random shard પર hit કરે છે, તેથી writes N rows પર ફેલાય છે અને parallel ચાલે છે. પ્રદર્શિત total એ `SUM(shards)` છે, જે aggregator દ્વારા દર એક-બે સેકન્ડે ગણાય છે. Redis માં આ માત્ર N `INCR` keys છે; DynamoDB માં, N partition keys.

## One-vote dedup

idempotency key વડે "એક યુઝર દીઠ એક vote" enforce કરો: `SADD voted:{pollId} {userId}` (અથવા conditional put). જો યુઝર પહેલેથી અસ્તિત્વમાં હોય, increment કરતાં પહેલાં event drop કરો. આ consumer માં કરો, client માં નહીં — clients જૂઠું બોલે છે અને retry કરે છે.

## ઇન્ટરવ્યૂ દૃષ્ટિકોણ

ઇન્ટરવ્યૂઅર probe કરી રહ્યા છે કે તમે **single-hot-key problem** ને ઓળખો છો અને "વધુ DB replicas ઉમેરો" ને બદલે buffering + sharding તરફ પહોંચો છો (replicas reads scale કરે છે, આ write નહીં). Good: "queue અને cache વાપરો." Great: તમે **eventual-consistency trade-off** નું નામ આપો છો — live number વાસ્તવિકતાથી એક સેકન્ડ પાછળ છે — અને દલીલ કરો છો કે vote count માટે તે ઠીક છે પણ final certified result માટે *નહીં*, જેને તમે poll બંધ થયા પછી authoritatively ફરી ગણો છો.

**સામાન્ય trap:** "accuracy" માટે પ્રતિ vote એક database transaction વાપરવું. આ scale પર એ જ વસ્તુ melt થાય છે.

## Trade-offs અને failure modes

- **Eventual tally:** shard sums lag કરે છે; 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

ઇન્ટરવ્યૂ દૃષ્ટિકોણ

Trade-offs અને failure modes

સંબંધિત પ્રશ્નો