Hvordan håndterer du 5M stemmer på 10 minutter i skala?

Question

IT Interview Practice · Accepted Answer

Ikke skriv hver stemme rett til en databaserad — **buffre writes, shard tellerne, og aksepter eventuell opptelling**. 5M stemmer på 10 minutter er ~8 300 stemmer/sek i snitt, med spikes langt høyere (et live TV-øyeblikk kan 10-doble det). Trikset er å gjøre en hot single-row-update om til mange uavhengige, parallelle inkrementer.

```text
Klient ─▶ Edge/API ─▶ Kafka (stemme-events) ─▶ Consumers ─┬─▶ Dedup-store (SET én-stemme)
                        (varig buffer)                    └─▶ Sharded tellere (INCR N shards)
                                                                     │
Redis/Aggregator ◀── periodisk sum av shards ─────────────────────┘
      │
      └─▶ Read replica / CDN cache ─▶ Live opptelling til klienter
```

## Hvorfor buffre writes

En kø som **Kafka** avkobler ingestion fra opptelling. Klient-writen er en billig append; hvis consumers henger etter under en spike, venter events i loggen i stedet for å overvelde DB-en. Kafka gir også **replay** — hvis en consumer krasjer, reprosesserer du fra siste committede offset uten å miste stemmer.

## Sharded tellere dreper hotspot-en

Hvis hver stemme for "Option A" gjør `UPDATE counter SET n=n+1 WHERE id='A'`, blir den ene raden en lock-contention-flaskehals — tusenvis av transaksjoner serialiseres på én rad. I stedet, del hvert alternativ i **N shard-rader** (`A:0 … A:63`). Hver inkrement treffer en tilfeldig shard, så writes sprer seg over N rader og kjører parallelt. Den viste totalen er `SUM(shards)`, beregnet hvert sekund eller to av en aggregator. I Redis er dette bare N `INCR`-keys; i DynamoDB, N partition keys.

## Én-stemme-dedup

Håndhev "én stemme per bruker" med en idempotensnøkkel: `SADD voted:{pollId} {userId}` (eller en conditional put). Hvis brukeren allerede finnes, dropp event-en før inkrementering. Gjør dette i consumeren, ikke klienten — klienter lyver og retryer.

## Intervjuperspektiv

Intervjueren undersøker om du gjenkjenner **single-hot-key-problemet** og griper til buffring + sharding fremfor "legg til flere DB replicas" (replicas skalerer lesninger, ikke denne writen). Bra: "bruk en kø og en cache." Utmerket: du navngir **eventual-consistency-avveiningen** — live-tallet henger et sekund etter virkeligheten — og argumenterer for at det er greit for en stemmetelling, men *ikke* for det endelige sertifiserte resultatet, som du rekomputerer autoritativt etter at avstemningen lukkes.

**Vanlig felle:** å bruke en databasetransaksjon per stemme for "nøyaktighet". I denne skalaen er det tingen som smelter.

## Avveininger og feilmoduser

- **Eventuell opptelling:** shard-summer henger etter; akseptabelt for en live-teller, avstem ved lukking.
- **At-least-once levering:** Kafka kan levere på nytt — dedup gjør inkrementer idempotente, ellers dobbellteller du.
- **Hot shard-skjevhet:** for få shards og du får fortsatt contention; for mange og summering blir dyrt. 32–128 shards er typisk.
- **Rettferdighet/svindel:** rate-limit per IP/enhet; én-stemme-SET-en er din integritetsgrense. Å miste den betyr ballot stuffing, ikke en krasj — uten tvil verre.

Hvorfor buffre writes

Sharded tellere dreper hotspot-en

Én-stemme-dedup

Intervjuperspektiv

Avveininger og feilmoduser

Relaterte spørsmål