Hogyan kezelsz 5M szavazatot 10 perc alatt nagy méretben?

Question

IT Interview Practice · Accepted Answer

Ne írj minden szavazatot közvetlenül egy adatbázissorba — **pufferelj írásokat, shardeld a számlálókat, és fogadd el az eventual összesítést**. 5M szavazat 10 perc alatt átlagosan ~8300 szavazat/mp, sokkal magasabb csúcsokkal (egy élő TV-pillanat ennek 10-szeresét is hozhatja). A trükk az, hogy egy forró egysoros frissítést sok független, párhuzamos inkrementté alakíts.

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

## Miért pufferelj írásokat

Egy queue, mint a **Kafka**, szétcsatolja a beolvasást az összesítéstől. A kliensírás egy olcsó append; ha a consumerek lemaradnak egy csúcs alatt, az események a logban várnak, ahelyett hogy elárasztanák az adatbázist. A Kafka **replayt** is ad — ha egy consumer összeomlik, az utoljára commitolt offsettől újrafeldolgozol szavazatvesztés nélkül.

## A shardelt számlálók megölik a hotspotot

Ha minden "A opció"-ra leadott szavazat `UPDATE counter SET n=n+1 WHERE id='A'`-t csinál, az az egy sor lock-versengési szűk keresztmetszetté válik — tranzakciók ezrei szerializálódnak egy soron. Ehelyett oszd fel minden opciót **N shard sorra** (`A:0 … A:63`). Minden inkrement egy véletlen shardot ér, így az írások szétterülnek N soron és párhuzamosan futnak. A megjelenített összeg `SUM(shards)`, amit egy aggregator másodpercenként-kettőnként számol. A Redisben ez csak N `INCR` kulcs; a DynamoDB-ben N partíciós kulcs.

## Egy-szavazat dedup

Kényszerítsd ki a "felhasználónként egy szavazat"-ot egy idempotencia kulccsal: `SADD voted:{pollId} {userId}` (vagy egy feltételes put). Ha a felhasználó már létezik, dobd el az eseményt az inkrement előtt. Ezt a consumerben csináld, ne a kliensben — a kliensek hazudnak és újrapróbálnak.

## Interjú szemszög

Az interjúztató azt vizsgálja, felismered-e az **egyetlen-forró-kulcs problémát**, és a pufferelés + shardelés felé nyúlsz-e ahelyett, hogy "adj hozzá több DB replikát" (a replikák az olvasásokat skálázzák, nem ezt az írást). Jó: "használj queue-t és cache-t." Kiváló: megnevezed az **eventual-consistency kompromisszumot** — az élő szám egy másodperccel lemarad a valóságtól — és érvelsz, hogy ez rendben van egy szavazatszámnál, *de nem* a végleges hitelesített eredménynél, amit tekintélyileg újraszámolsz a szavazás lezárása után.

**Gyakori csapda:** adatbázis-tranzakció szavazatonként a "pontosságért". Ebben a méretben pont ez az, ami megolvad.

## Kompromisszumok és hibamódok

- **Eventual összesítés:** a shard-összegek lemaradnak; elfogadható egy élő számlálónál, egyeztetés lezáráskor.
- **At-least-once kézbesítés:** a Kafka újraküldhet — a dedup idempotenssé teszi az inkrementeket, különben duplán számolsz.
- **Forró shard ferdeség:** túl kevés shard és még mindig versengsz; túl sok és az összegzés drágul. 32–128 shard a tipikus.
- **Fairség/csalás:** rate-limitelj IP/eszközönként; az egy-szavazat SET az integritási határod. Elvesztése ballot stuffinget jelent, nem összeomlást — vitathatóan rosszabb.

Miért pufferelj írásokat

A shardelt számlálók megölik a hotspotot

Egy-szavazat dedup

Interjú szemszög

Kompromisszumok és hibamódok

Kapcsolódó kérdések