Jak zvládnete 5 milionů hlasů za 10 minut ve velkém měřítku?

Question

IT Interview Practice · Accepted Answer

Nezapisujte každý hlas rovnou do řádku databáze — **bufferujte zápisy, shardujte čítače a akceptujte eventuální sečtení**. 5 milionů hlasů za 10 minut je průměrně ~8 300 hlasů/s, se špičkami mnohem vyššími (živý televizní okamžik to může 10× zvednout). Trik spočívá v tom, proměnit hot aktualizaci jednoho řádku na mnoho nezávislých paralelních 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
```

## Proč bufferovat zápisy

Fronta jako **Kafka** oddělí příjem (ingestion) od sčítání. Klientský zápis je levný append; pokud consumeři při špičce zaostávají, události čekají v logu místo aby zahltily DB. Kafka dává i **replay** — když consumer spadne, přezpracujete od posledního committed offsetu bez ztráty hlasů.

## Shardované čítače zabijí hotspot

Pokud každý hlas pro „Option A“ dělá `UPDATE counter SET n=n+1 WHERE id='A'`, stane se z toho jednoho řádku úzké hrdlo s lock-contention — tisíce transakcí se serializují na jednom řádku. Místo toho rozdělte každou možnost na **N shard řádků** (`A:0 … A:63`). Každý inkrement zasáhne náhodný shard, takže zápisy se rozprostřou napříč N řádky a běží paralelně. Zobrazený součet je `SUM(shards)`, počítaný každou sekundu či dvě agregátorem. V Redisu je to prostě N `INCR` klíčů; v DynamoDB N partition keys.

## Dedup jednoho hlasu

Vynuťte „jeden hlas na uživatele“ idempotenčním klíčem: `SADD voted:{pollId} {userId}` (nebo podmíněný put). Pokud uživatel už existuje, zahoďte událost před inkrementem. Dělejte to v consumeru, ne v klientovi — klienti lžou a retryují.

## Pohled z pohovoru

Tazatel zkoumá, zda rozpoznáte **problém jednoho hot key** a sáhnete po bufferování + shardingu spíš než „přidej víc DB replik“ (repliky škálují čtení, ne tento zápis). Dobré: „použij frontu a cache.“ Skvělé: pojmenujete **kompromis eventual-consistency** — živé číslo zaostává za realitou o sekundu — a zdůvodníte, že to je v pořádku pro počet hlasů, ale *ne* pro finální certifikovaný výsledek, který po uzavření hlasování autoritativně přepočítáte.

**Častá past:** použití databázové transakce na každý hlas kvůli „přesnosti“. V tomto měřítku je to přesně to, co roztaje.

## Kompromisy a režimy selhání

- **Eventuální sečtení:** součty shardů zaostávají; přijatelné pro živý čítač, odsouhlaste při uzávěrce.
- **At-least-once doručení:** Kafka může znovudoručit — dedup činí inkrementy idempotentními, jinak počítáte dvakrát.
- **Skew hot shardu:** příliš málo shardů a stále se soupeříte; příliš mnoho a sčítání se prodraží. 32–128 shardů je typické.
- **Férovost/podvody:** rate-limitujte na IP/zařízení; SET jednoho hlasu je vaše hranice integrity. Jeho ztráta znamená ballot stuffing, nikoli pád — pravděpodobně horší.

Proč bufferovat zápisy

Shardované čítače zabijí hotspot

Dedup jednoho hlasu

Pohled z pohovoru

Kompromisy a režimy selhání

Související otázky