Hoe verwerk je 5 miljoen stemmen in 10 minuten op schaal?

Question

IT Interview Practice · Accepted Answer

Schrijf niet elke stem direct naar een databaserow — **buffer writes, shard de tellers, en accepteer een eventuele telling**. 5 miljoen stemmen in 10 minuten is gemiddeld ~8.300 stemmen/sec, met pieken die veel hoger liggen (een live tv-moment kan dat vertienvoudigen). De truc is één hot single-row update om te zetten in veel onafhankelijke, parallelle verhogingen.

```text
Client ─▶ Edge/API ─▶ Kafka (stem-events) ─▶ Consumers ─┬─▶ Dedup store (SET één-stem)
                        (duurzame buffer)                 └─▶ Gesharde tellers (INCR N shards)
                                                                     │
Redis/Aggregator ◀── periodieke som van shards ───────────────────┘
      │
      └─▶ Read replica / CDN cache ─▶ Live telling naar clients
```

## Waarom writes bufferen

Een queue als **Kafka** ontkoppelt ingestie van tellen. De client-write is een goedkope append; als consumers achterlopen tijdens een piek, wachten events in de log in plaats van de DB te overweldigen. Kafka geeft ook **replay** — als een consumer crasht, herwerk je vanaf de laatst gecommitte offset zonder stemmen te verliezen.

## Gesharde tellers doden de hotspot

Als elke stem voor "Optie A" `UPDATE counter SET n=n+1 WHERE id='A'` doet, wordt die ene row een lock-contentie-bottleneck — duizenden transacties serialiseren op één row. Splits in plaats daarvan elke optie in **N shard-rows** (`A:0 … A:63`). Elke verhoging raakt een willekeurige shard, zodat writes over N rows spreiden en parallel draaien. Het getoonde totaal is `SUM(shards)`, elke seconde of twee berekend door een aggregator. In Redis is dit gewoon N `INCR` keys; in DynamoDB, N partition keys.

## Één-stem-dedup

Dwing "één stem per gebruiker" af met een idempotency key: `SADD voted:{pollId} {userId}` (of een conditional put). Als de gebruiker al bestaat, drop het event vóór het verhogen. Doe dit in de consumer, niet in de client — clients liegen en retryen.

## Interviewperspectief

De interviewer peilt of je het **single-hot-key-probleem** herkent en grijpt naar bufferen + sharden in plaats van "voeg meer DB-replica's toe" (replica's schalen reads, niet deze write). Goed: "gebruik een queue en een cache." Uitstekend: je benoemt de **eventual-consistency-afweging** — het live-getal loopt een seconde achter op de werkelijkheid — en beargumenteert dat dat prima is voor een stemtelling maar *niet* voor het uiteindelijke gecertificeerde resultaat, dat je na sluiting van de stemming autoritatief herberekent.

**Veelvoorkomende valkuil:** een databasetransactie per stem gebruiken voor "nauwkeurigheid." Op deze schaal is dat juist wat smelt.

## Afwegingen & faalmodi

- **Eventuele telling:** shard-sommen lopen achter; acceptabel voor een live teller, reconcileer bij sluiting.
- **At-least-once bezorging:** Kafka kan opnieuw bezorgen — dedup maakt verhogingen idempotent, anders tel je dubbel.
- **Hot shard skew:** te weinig shards en je hebt nog steeds contentie; te veel en sommeren wordt duur. 32–128 shards is typisch.
- **Eerlijkheid/fraude:** rate-limit per IP/device; de één-stem-SET is je integriteitsgrens. Hem verliezen betekent ballot stuffing, geen crash — wellicht erger.

Waarom writes bufferen

Gesharde tellers doden de hotspot

Één-stem-dedup

Interviewperspectief

Afwegingen & faalmodi

Gerelateerde vragen