Hur hanterar du 5M röster på 10 minuter i stor skala?

Question

IT Interview Practice · Accepted Answer

Skriv inte varje röst direkt till en databasrad — **buffra skrivningar, sharda räknarna och acceptera eventuell sammanräkning**. 5M röster på 10 minuter är ~8 300 röster/sek i snitt, med toppar långt högre (ett live-TV-ögonblick kan 10-dubbla det). Tricket är att förvandla en het enradsuppdatering till många oberoende, parallella inkrement.

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

## Varför buffra skrivningarna

En kö som **Kafka** frikopplar ingestion från sammanräkning. Klientskrivningen är ett billigt append; om consumers hamnar efter under en topp väntar händelserna i loggen istället för att överväldiga DB:n. Kafka ger också **replay** — om en consumer kraschar bearbetar du om från den senast committade offset:en utan att förlora röster.

## Shardade räknare dödar hotspoten

Om varje röst för "Option A" gör `UPDATE counter SET n=n+1 WHERE id='A'` blir den enda raden en låscontention-flaskhals — tusentals transaktioner serialiseras på en rad. Dela istället upp varje alternativ i **N shard-rader** (`A:0 … A:63`). Varje inkrement träffar en slumpmässig shard, så skrivningar sprids över N rader och körs parallellt. Den visade totalen är `SUM(shards)`, beräknad varje sekund eller två av en aggregator. I Redis är detta bara N `INCR`-nycklar; i DynamoDB, N partition keys.

## En-röst-dedup

Upprätthåll "en röst per användare" med en idempotensnyckel: `SADD voted:{pollId} {userId}` (eller en villkorlig put). Om användaren redan finns, släpp händelsen före inkrementering. Gör detta i consumern, inte i klienten — klienter ljuger och omförsöker.

## Intervjuperspektiv

Intervjuaren undersöker om du känner igen **problemet med en enda het nyckel** och griper efter buffring + sharding istället för "lägg till fler DB-replicas" (replicas skalar läsningar, inte denna skrivning). Bra: "använd en kö och en cache." Utmärkt: du namnger **eventual-consistency-avvägningen** — livesiffran ligger efter verkligheten med en sekund — och argumenterar att det är okej för ett röstantal men *inte* för det slutliga certifierade resultatet, som du räknar om auktoritativt efter att omröstningen stängt.

**Vanlig fälla:** att använda en databastransaktion per röst för "noggrannhet". I den här skalan är det just det som smälter.

## Avvägningar & felmoder

- **Eventuell sammanräkning:** shard-summor ligger efter; acceptabelt för en liveräknare, stäm av vid stängning.
- **At-least-once-leverans:** Kafka kan omleverera — dedup gör inkrement idempotenta, annars dubbelräknar du.
- **Het shard-skevhet:** för få shards och du har fortfarande contention; för många och summeringen blir dyr. 32–128 shards är typiskt.
- **Rättvisa/bedrägeri:** rate-limita per IP/enhet; en-röst-SET:en är din integritetsgräns. Att förlora den betyder valfusk, inte en krasch — utan tvekan värre.

Varför buffra skrivningarna

Shardade räknare dödar hotspoten

En-röst-dedup

Intervjuperspektiv

Avvägningar & felmoder

Relaterade frågor