Si i menaxhoni 5M vota në 10 minuta në shkallë?

Question

IT Interview Practice · Accepted Answer

Mos shkruani çdo votë drejt e në një row të bazës së të dhënave — **buffer-oni shkrimet, shard-oni counter-at, dhe pranoni një numërim eventual**. 5M vota në 10 minuta janë ~8,300 vota/sek mesatarisht, me spikes shumë më të larta (një moment live në TV mund ta 10-fishojë atë). Truku është ta ktheni një update të vetëm në një row të nxehtë në shumë increments të pavarur e paralelë.

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

## Pse të buffer-osh shkrimet

Një queue si **Kafka** bën decouple të ingestion nga numërimi. Shkrimi i klientit është një append i lirë; nëse consumers ngelin prapa gjatë një spike, event-et presin në log në vend që të mbytin DB-në. Kafka jep gjithashtu **replay** — nëse një consumer rrëzohet, ri-procesoni nga offset-i i fundit i committed pa humbur vota.

## Sharded counters vrasin hotspot-in

Nëse çdo votë për "Option A" bën `UPDATE counter SET n=n+1 WHERE id='A'`, ai row i vetëm bëhet një bottleneck lock-contention — mijëra transaksione serializohen në një row. Në vend të kësaj, ndani çdo opsion në **N shard rows** (`A:0 … A:63`). Çdo increment godet një shard të rastësishëm, kështu që shkrimet shpërndahen nëpër N rreshta dhe ekzekutohen paralelisht. Totali i shfaqur është `SUM(shards)`, i llogaritur çdo sekondë a dy nga një aggregator. Në Redis kjo është thjesht N key `INCR`; në DynamoDB, N partition keys.

## Dedup një-votë

Zbatoni "një votë për përdorues" me një idempotency key: `SADD voted:{pollId} {userId}` (ose një conditional put). Nëse përdoruesi ekziston tashmë, hidhni event-in para se të bëni increment. Bëjeni këtë në consumer, jo në klient — klientët gënjejnë dhe riprovojnë.

## Këndvështrimi i intervistës

Intervistuesi po heton nëse e njihni **problemin single-hot-key** dhe kapeni pas buffering + sharding në vend të "shto më shumë DB replica" (replica-t shkallëzojnë leximet, jo këtë shkrim). Mirë: "përdor një queue dhe një cache." E shkëlqyer: emërton **kompromisin e eventual-consistency** — numri live vonon realitetin me një sekondë — dhe argumenton se kjo është në rregull për një numërim votash por *jo* për rezultatin final të certifikuar, të cilin e rillogaritni në mënyrë autoritative pasi mbyllet sondazhi.

**Kurthi i zakonshëm:** përdorimi i një transaction të bazës së të dhënave për çdo votë për "saktësi". Në këtë shkallë kjo është pikërisht gjëja që shkrihet.

## Kompromiset & mënyrat e dështimit

- **Numërim eventual:** shumat e shard-eve vonojnë; e pranueshme për një counter live, rakordoni në mbyllje.
- **Dorëzim at-least-once:** Kafka mund të ridërgojë — dedup i bën increments idempotent, përndryshe numëroni dy herë.
- **Hot shard skew:** shumë pak shards dhe ende keni contention; shumë të tepërt dhe mbledhja bëhet e shtrenjtë. 32–128 shards është tipike.
- **Ndershmëri/mashtrim:** rate-limit për çdo IP/pajisje; SET-i një-votë është kufiri juaj i integritetit. Humbja e tij do të thotë ballot stuffing, jo një crash — ndoshta më keq.

Pse të buffer-osh shkrimet

Sharded counters vrasin hotspot-in

Dedup një-votë

Këndvështrimi i intervistës

Kompromiset & mënyrat e dështimit

Pyetje të ngjashme