Kako obraditi 5 milijuna glasova u 10 minuta na velikoj skali?

Question

IT Interview Practice · Accepted Answer

Ne zapisujte svaki glas izravno u redak baze podataka — **bufferirajte upise, shardirajte brojače i prihvatite eventualni zbroj**. 5 milijuna glasova u 10 minuta je u prosjeku ~8.300 glasova/s, uz skokove daleko veće (trenutak uživo na TV-u može to 10-erostručiti). Trik je pretvoriti vruće ažuriranje jednog retka u mnogo neovisnih, paralelnih inkrementa.

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

## Zašto bufferirati upise

Queue poput **Kafke** razdvaja unos od zbrajanja. Klijentski upis je jeftin append; ako consumeri zaostaju tijekom skoka, događaji čekaju u logu umjesto da preplave bazu. Kafka također daje **replay** — ako se consumer sruši, ponovno obrađujete od zadnjeg commitanog offseta bez gubitka glasova.

## Shardirani brojači ubijaju hotspot

Ako svaki glas za "Opciju A" radi `UPDATE counter SET n=n+1 WHERE id='A'`, taj jedan redak postaje usko grlo zbog borbe za zaključavanje — tisuće transakcija serijaliziraju se na jednom retku. Umjesto toga, podijelite svaku opciju na **N shard redaka** (`A:0 … A:63`). Svaki inkrement pogađa nasumičan shard, pa se upisi šire preko N redaka i teku paralelno. Prikazani ukupni broj je `SUM(shards)`, izračunat svake sekunde ili dvije od strane agregatora. U Redisu je to samo N `INCR` ključeva; u DynamoDB-u, N particijskih ključeva.

## Dedup jednog glasa

Provedite "jedan glas po korisniku" idempotentnim ključem: `SADD voted:{pollId} {userId}` (ili uvjetni put). Ako korisnik već postoji, odbacite događaj prije inkrementiranja. Radite ovo u consumeru, ne u klijentu — klijenti lažu i ponavljaju.

## Perspektiva intervjua

Ispitivač provjerava prepoznajete li **problem jednog vrućeg ključa** i posežete li za bufferiranjem + shardingom umjesto "dodaj još DB replika" (replike skaliraju čitanja, ne ovaj upis). Dobro: "koristi queue i cache." Odlično: imenujete **kompromis eventualne konzistentnosti** — živi broj zaostaje za stvarnošću sekundu — i tvrdite da je to u redu za broj glasova, ali *ne* za konačni ovjereni rezultat, koji autoritativno ponovno izračunate nakon zatvaranja glasanja.

**Uobičajena zamka:** korištenje transakcije baze po glasu radi "točnosti". Na ovoj skali upravo se to topi.

## Kompromisi i načini otkazivanja

- **Eventualni zbroj:** zbrojevi shardova zaostaju; prihvatljivo za živi brojač, uskladite pri zatvaranju.
- **At-least-once isporuka:** Kafka može ponovno isporučiti — dedup čini inkremente idempotentnima, inače dvostruko brojite.
- **Neravnomjernost vrućih shardova:** premalo shardova i i dalje se borite; previše i zbrajanje postaje skupo. 32–128 shardova je tipično.
- **Poštenost/prijevara:** rate-limitirajte po IP-u/uređaju; SET jednog glasa je vaša granica integriteta. Njegov gubitak znači nabijanje glasačke kutije, ne pad — vjerojatno gore.

Zašto bufferirati upise

Shardirani brojači ubijaju hotspot

Dedup jednog glasa

Perspektiva intervjua

Kompromisi i načini otkazivanja

Povezana pitanja