Wie bewältigst du 5 Mio. Stimmen in 10 Minuten bei großem Maßstab?

Question

IT Interview Practice · Accepted Answer

Schreibe nicht jede Stimme direkt in eine Datenbank-Row - **puffere Writes, sharde die Zähler und akzeptiere eine eventuelle Auszählung**. 5 Mio. Stimmen in 10 Minuten sind im Schnitt ~8.300 Stimmen/Sek., mit weit höheren Spitzen (ein Live-TV-Moment kann das ver-10-fachen). Der Trick besteht darin, ein heißes Single-Row-Update in viele unabhängige, parallele Inkremente zu verwandeln.

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

## Warum die Writes puffern

Eine Queue wie **Kafka** entkoppelt Ingestion von Auszählung. Der Client-Write ist ein günstiges Append; fallen Consumer während einer Spitze zurück, warten Events im Log, statt die DB zu überrollen. Kafka bietet außerdem **Replay** - stürzt ein Consumer ab, verarbeitest du ab dem letzten committeten Offset neu, ohne Stimmen zu verlieren.

## Sharded Counters beseitigen den Hotspot

Wenn jede Stimme für "Option A" ein `UPDATE counter SET n=n+1 WHERE id='A'` ausführt, wird diese eine Row zum Lock-Contention-Engpass - Tausende Transaktionen serialisieren auf einer Row. Splitte stattdessen jede Option in **N Shard-Rows** (`A:0 … A:63`). Jedes Inkrement trifft einen zufälligen Shard, sodass Writes sich über N Rows verteilen und parallel laufen. Der angezeigte Gesamtwert ist `SUM(shards)`, jede Sekunde oder zwei von einem Aggregator berechnet. In Redis sind das einfach N `INCR`-Keys; in DynamoDB N Partition Keys.

## One-Vote-Dedup

Erzwinge "eine Stimme pro Nutzer" mit einem Idempotency Key: `SADD voted:{pollId} {userId}` (oder ein Conditional Put). Existiert der Nutzer bereits, verwirf das Event vor dem Inkrementieren. Tu das im Consumer, nicht im Client - Clients lügen und wiederholen.

## Interview-Perspektive

Der Interviewer sondiert, ob du das **Single-Hot-Key-Problem** erkennst und zu Puffern + Sharding greifst statt zu "mehr DB-Replicas hinzufügen" (Replicas skalieren Reads, nicht diesen Write). Gut: "eine Queue und einen Cache verwenden." Hervorragend: Du benennst den **Eventual-Consistency-Trade-off** - die Live-Zahl hinkt der Realität um eine Sekunde hinterher - und argumentierst, dass das für einen Stimmenzähler in Ordnung ist, *aber nicht* für das finale zertifizierte Ergebnis, das du nach Schließung der Abstimmung autoritativ neu berechnest.

**Häufige Falle:** eine Datenbanktransaktion pro Stimme zur "Genauigkeit". In diesem Maßstab ist genau das, was schmilzt.

## Trade-offs & Fehlermodi

- **Eventuelle Auszählung:** Shard-Summen hinken hinterher; akzeptabel für einen Live-Zähler, Abgleich bei Schließung.
- **At-least-once-Zustellung:** Kafka kann erneut zustellen - Dedup macht Inkremente idempotent, sonst zählst du doppelt.
- **Hot-Shard-Skew:** zu wenige Shards und du hast weiterhin Contention; zu viele und das Summieren wird teuer. 32-128 Shards sind typisch.
- **Fairness/Betrug:** Rate-Limit pro IP/Gerät; das One-Vote-SET ist deine Integritätsgrenze. Es zu verlieren bedeutet Ballot Stuffing, keinen Crash - wohl schlimmer.

Warum die Writes puffern

Sharded Counters beseitigen den Hotspot

One-Vote-Dedup

Interview-Perspektive

Trade-offs & Fehlermodi

Ähnliche Fragen