Jak obsłużyć 5 mln głosów w 10 minut w dużej skali?

Question

IT Interview Practice · Accepted Answer

Nie zapisuj każdego głosu wprost do wiersza bazy danych — **buforuj zapisy, sharduj liczniki i akceptuj ostateczne zliczenie (eventual tally)**. 5 mln głosów w 10 minut to średnio ~8 300 głosów/s, ze skokami znacznie wyższymi (moment na żywo w TV może dać 10x tyle). Sztuczka polega na zamianie aktualizacji jednego gorącego wiersza na wiele niezależnych, równoległych inkrementacji.

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

## Dlaczego buforować zapisy

Kolejka taka jak **Kafka** odseparowuje przyjmowanie od zliczania. Zapis klienta to tani append; jeśli konsumenci nie nadążają podczas skoku, zdarzenia czekają w logu, zamiast przytłaczać DB. Kafka daje też **replay** — jeśli konsument padnie, przetwarzasz ponownie od ostatniego zatwierdzonego offsetu bez utraty głosów.

## Shardowane liczniki eliminują hotspot

Jeśli każdy głos na „Opcję A" robi `UPDATE counter SET n=n+1 WHERE id='A'`, ten jeden wiersz staje się wąskim gardłem rywalizacji o blokady — tysiące transakcji serializuje się na jednym wierszu. Zamiast tego podziel każdą opcję na **N wierszy shardów** (`A:0 … A:63`). Każda inkrementacja trafia na losowy shard, więc zapisy rozkładają się na N wierszy i biegną równolegle. Wyświetlana suma to `SUM(shards)`, obliczana co sekundę lub dwie przez agregator. W Redis to po prostu N kluczy `INCR`; w DynamoDB — N kluczy partycji.

## Dedupikacja jednego głosu

Wymuś „jeden głos na użytkownika" kluczem idempotentności: `SADD voted:{pollId} {userId}` (lub warunkowy put). Jeśli użytkownik już istnieje, odrzuć zdarzenie przed inkrementacją. Rób to w konsumencie, nie w kliencie — klienci kłamią i ponawiają.

## Perspektywa rozmowy kwalifikacyjnej

Rozmówca sonduje, czy rozpoznajesz **problem pojedynczego gorącego klucza** i sięgasz po buforowanie + shardowanie, zamiast „dodaj więcej replik DB" (repliki skalują odczyty, nie ten zapis). Dobrze: „użyj kolejki i cache". Świetnie: nazywasz **kompromis spójności ostatecznej** — liczba na żywo jest opóźniona względem rzeczywistości o sekundę — i argumentujesz, że to OK dla licznika głosów, ale *nie* dla finalnego certyfikowanego wyniku, który przeliczasz autorytatywnie po zamknięciu głosowania.

**Częsta pułapka:** użycie transakcji bazodanowej na głos dla „dokładności". W tej skali to właśnie to się topi.

## Kompromisy i tryby awarii

- **Ostateczne zliczenie:** sumy shardów są opóźnione; akceptowalne dla licznika na żywo, uzgadniaj przy zamknięciu.
- **Dostarczanie at-least-once:** Kafka może dostarczyć ponownie — dedupikacja czyni inkrementacje idempotentnymi, inaczej liczysz podwójnie.
- **Skew gorącego sharda:** za mało shardów i wciąż rywalizujesz; za dużo i sumowanie staje się kosztowne. Typowo 32–128 shardów.
- **Uczciwość/oszustwa:** ogranicz tempo per IP/urządzenie; SET jednego głosu jest twoją granicą integralności. Jego utrata oznacza fałszowanie głosów, nie awarię — chyba gorsze.

Dlaczego buforować zapisy

Shardowane liczniki eliminują hotspot

Dedupikacja jednego głosu

Perspektywa rozmowy kwalifikacyjnej

Kompromisy i tryby awarii

Powiązane pytania