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

Question

IT Interview Practice · Accepted Answer

Skriv ikke hver stemme direkte til en database-row — **buffer writes, shard tællerne, og accepter eventuel optælling**. 5M stemmer på 10 minutter er ~8.300 stemmer/sek i gennemsnit, med spikes langt højere (et live TV-øjeblik kan 10-doble det). Tricket er at gøre en hot single-row-update til mange uafhængige, parallelle increments.

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

## Hvorfor buffere writes

En queue som **Kafka** decoupler ingestion fra optælling. Client-write'et er en billig append; hvis consumers sakker bagud under en spike, venter events i loggen frem for at overvælde DB'en. Kafka giver også **replay** — hvis en consumer crasher, genbehandler du fra sidste committede offset uden at miste stemmer.

## Sharded counters dræber hotspottet

Hvis hver stemme på "Option A" kører `UPDATE counter SET n=n+1 WHERE id='A'`, bliver den ene row en lock-kontentions-flaskehals — tusindvis af transactions serialiserer på én row. I stedet, split hver option i **N shard-rows** (`A:0 … A:63`). Hvert increment rammer en tilfældig shard, så writes spreder sig over N rows og kører parallelt. Den viste total er `SUM(shards)`, beregnet hvert sekund eller to af en aggregator. I Redis er dette bare N `INCR`-nøgler; i DynamoDB, N partition keys.

## One-vote dedup

Håndhæv "én stemme pr. bruger" med en idempotency key: `SADD voted:{pollId} {userId}` (eller en conditional put). Hvis brugeren allerede findes, drop eventet før increment. Gør dette i consumeren, ikke i clienten — clients lyver og genforsøger.

## Interview-perspektiv

Intervieweren undersøger, om du genkender **single-hot-key-problemet** og griber efter buffering + sharding frem for "tilføj flere DB-replicas" (replicas skalerer reads, ikke dette write). Godt: "brug en queue og en cache." Fremragende: du navngiver **eventual-consistency-trade-off'et** — det live tal sakker et sekund bag virkeligheden — og argumenterer for, at det er fint for en stemmetæller, men *ikke* for det endelige certificerede resultat, som du genberegner autoritativt efter afstemningen lukker.

**Almindelig fælde:** at bruge en database-transaction pr. stemme for "nøjagtighed". I denne skala er det netop det, der smelter.

## Trade-offs & fejlmåder

- **Eventuel optælling:** shard-summer sakker; acceptabelt for en live-tæller, afstem ved lukning.
- **At-least-once delivery:** Kafka kan genlevere — dedup gør increments idempotente, ellers dobbelttæller du.
- **Hot shard skew:** for få shards og du kontenderer stadig; for mange og summering bliver dyr. 32–128 shards er typisk.
- **Retfærdighed/svindel:** rate-limit pr. IP/enhed; one-vote-SET'et er din integritetsgrænse. At miste det betyder ballot stuffing, ikke et crash — velsagtens værre.

Hvorfor buffere writes

Sharded counters dræber hotspottet

One-vote dedup

Interview-perspektiv

Trade-offs & fejlmåder

Relaterede spørgsmål