Cum gestionezi 5M de voturi în 10 minute la scară?

Question

IT Interview Practice · Accepted Answer

Nu scrie fiecare vot direct într-un rând de bază de date — **fă buffering la scrieri, sharding la contoare și acceptă un total eventual**. 5M de voturi în 10 minute înseamnă ~8.300 voturi/sec în medie, cu vârfuri mult mai mari (un moment TV live poate face 10x). Trucul este să transformi un update fierbinte pe un singur rând în multe incrementări independente, paralele.

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

## De ce să faci buffering la scrieri

O coadă precum **Kafka** decuplează ingestia de numărare. Scrierea clientului este un append ieftin; dacă consumerii rămân în urmă în timpul unui vârf, evenimentele așteaptă în log în loc să copleșească DB-ul. Kafka oferă și **replay** — dacă un consumer cade, reprocesezi de la ultimul offset committed fără să pierzi voturi.

## Contoarele sharded elimină hotspot-ul

Dacă fiecare vot pentru "Opțiunea A" face `UPDATE counter SET n=n+1 WHERE id='A'`, acel singur rând devine un blocaj de contenție pe lock — mii de tranzacții se serializează pe un rând. În schimb, împarte fiecare opțiune în **N rânduri de shard** (`A:0 … A:63`). Fiecare incrementare lovește un shard aleator, deci scrierile se distribuie pe N rânduri și rulează în paralel. Totalul afișat este `SUM(shards)`, calculat la fiecare secundă sau două de un agregator. În Redis, acestea sunt doar N chei `INCR`; în DynamoDB, N chei de partiție.

## Dedup pentru un singur vot

Aplică "un vot per utilizator" cu o cheie de idempotență: `SADD voted:{pollId} {userId}` (sau un conditional put). Dacă utilizatorul există deja, elimină evenimentul înainte de a incrementa. Fă asta în consumer, nu în client — clienții mint și reîncearcă.

## Perspectiva de interviu

Intervievatorul sondează dacă recunoști **problema cheii-fierbinți-unice** și apelezi la buffering + sharding în loc de "adaugă mai multe replici de DB" (replicile scalează citirile, nu această scriere). Bine: "folosește o coadă și un cache." Excelent: numești **compromisul de consistență eventuală** — numărul live este în urma realității cu o secundă — și argumentezi că e în regulă pentru un număr de voturi, dar *nu* pentru rezultatul final certificat, pe care îl recalculezi autoritar după închiderea votării.

**Capcană obișnuită:** folosirea unei tranzacții de bază de date per vot pentru "acuratețe". La această scară, exact asta se topește.

## Compromisuri și moduri de eșec

- **Total eventual:** sumele de shard-uri sunt în urmă; acceptabil pentru un contor live, reconciliază la închidere.
- **Livrare at-least-once:** Kafka poate redistribui — dedup-ul face incrementările idempotente, altfel numeri de două ori.
- **Dezechilibru de shard fierbinte (hot shard skew):** prea puține shard-uri și încă ai contenție; prea multe și însumarea devine costisitoare. 32–128 de shard-uri este tipic.
- **Corectitudine/fraudă:** rate-limit per IP/dispozitiv; SET-ul de un-singur-vot este granița ta de integritate. Pierderea lui înseamnă ballot stuffing, nu un crash — arguabil mai rău.

De ce să faci buffering la scrieri

Contoarele sharded elimină hotspot-ul

Dedup pentru un singur vot

Perspectiva de interviu

Compromisuri și moduri de eșec

Întrebări conexe