Unashughulikiaje kura milioni 5 katika dakika 10 kwenye scale?

Question

IT Interview Practice · Accepted Answer

Usiandike kila kura moja kwa moja kwenye database row — **buffer writes, shard counters, na kubali eventual tally**. Kura milioni 5 katika dakika 10 ni wastani wa ~8,300 kura/sekunde, zenye spikes za juu zaidi (dakika ya TV ya moja kwa moja inaweza kuzidisha mara 10). Hila ni kubadilisha update ya hot single-row kuwa maongezeko mengi yanayojitegemea, sambamba.

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

## Kwa nini buffer writes

Queue kama **Kafka** hutenganisha ingestion na tallying. Write ya client ni append nafuu; ikiwa consumers watabaki nyuma wakati wa spike, matukio husubiri kwenye log badala ya kulemea DB. Kafka pia hutoa **replay** — ikiwa consumer itaanguka, unaprocess tena kutoka offset ya mwisho iliyocommit bila kupoteza kura.

## Sharded counters huua hotspot

Ikiwa kila kura ya "Option A" hufanya `UPDATE counter SET n=n+1 WHERE id='A'`, row hiyo moja huwa bottleneck ya lock-contention — maelfu ya transactions hupanga mfululizo kwenye row moja. Badala yake, gawanya kila option kuwa **N shard rows** (`A:0 … A:63`). Kila ongezeko hupiga shard ya bahati nasibu, hivyo writes husambaa kwenye N rows na kuendeshwa sambamba. Jumla inayooneshwa ni `SUM(shards)`, iliyohesabiwa kila sekunde moja au mbili na aggregator. Katika Redis hii ni N `INCR` keys tu; katika DynamoDB, N partition keys.

## One-vote dedup

Tekeleza "kura moja kwa kila mtumiaji" kwa idempotency key: `SADD voted:{pollId} {userId}` (au conditional put). Ikiwa mtumiaji tayari yupo, dondosha tukio kabla ya kuongeza. Fanya hili katika consumer, si client — clients husema uongo na kujaribu tena.

## Mtazamo wa mahojiano

Mhojiwa anachunguza kama unatambua **tatizo la single-hot-key** na kukimbilia buffering + sharding badala ya "ongeza DB replicas zaidi" (replicas huscale reads, si write hii). Nzuri: "tumia queue na cache." Bora sana: unataja **eventual-consistency trade-off** — namba ya moja kwa moja huchelewa nyuma ya uhalisia kwa sekunde — na kubishana kuwa hilo ni sawa kwa hesabu ya kura lakini *si* kwa matokeo ya mwisho yaliyothibitishwa, ambayo unayahesabu upya kwa mamlaka baada ya poll kufungwa.

**Mtego wa kawaida:** kutumia database transaction kwa kila kura kwa "usahihi." Kwenye scale hii hilo ndilo linaloyeyuka.

## Maelewano na aina za hitilafu

- **Eventual tally:** shard sums huchelewa; inakubalika kwa counter ya moja kwa moja, linganisha wakati wa kufunga.
- **At-least-once delivery:** Kafka inaweza kutuma tena — dedup hufanya maongezeko kuwa idempotent, la sivyo unahesabu mara mbili.
- **Hot shard skew:** shards chache mno bado unagombana; nyingi mno na kujumlisha kunakuwa ghali. Shards 32–128 ni kawaida.
- **Haki/udanganyifu:** weka rate-limit kwa kila IP/kifaa; one-vote SET ndiyo mpaka wako wa uadilifu. Kuipoteza kunamaanisha ballot stuffing, si crash — pengine mbaya zaidi.

Kwa nini buffer writes

Sharded counters huua hotspot

One-vote dedup

Mtazamo wa mahojiano

Maelewano na aina za hitilafu

Maswali yanayohusiana