Miten käsittelet 5M ääntä 10 minuutissa mittakaavassa?

Question

IT Interview Practice · Accepted Answer

Älä kirjoita jokaista ääntä suoraan tietokantariville — **puskuroi kirjoitukset, shardaa laskurit ja hyväksy eventual tally (lopullinen summaus viiveellä)**. 5M ääntä 10 minuutissa on ~8 300 ääntä/s keskimäärin, piikkien ollessa paljon korkeampia (live-TV-hetki voi 10-kertaistaa sen). Temppu on muuttaa kuuma yhden rivin päivitys moniksi itsenäisiksi rinnakkaisiksi inkrementeiksi.

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

## Miksi puskuroida kirjoitukset

Jono kuten **Kafka** irtikytkee sisäänoton (ingestion) summauksesta. Client-kirjoitus on halpa append; jos consumerit jäävät jälkeen piikin aikana, tapahtumat odottavat lokissa sen sijaan, että ne hukuttaisivat DB:n. Kafka antaa myös **replayn** — jos consumer kaatuu, prosessoit uudelleen viimeisimmästä committoidusta offsetista menettämättä ääniä.

## Shardatut laskurit tappavat hotspotin

Jos jokainen "Option A":n ääni tekee `UPDATE counter SET n=n+1 WHERE id='A'`, tuosta yhdestä rivistä tulee lukkokilpailun pullonkaula — tuhannet transaktiot serialisoituvat yhdelle riville. Sen sijaan jaa jokainen vaihtoehto **N shard-riviin** (`A:0 … A:63`). Jokainen inkrementti osuu satunnaiseen shardiin, joten kirjoitukset leviävät N rivin yli ja ajautuvat rinnakkain. Näytetty kokonaissumma on `SUM(shards)`, laskettuna sekunnin tai kahden välein aggregaattorilla. Redisissä tämä on vain N `INCR`-avainta; DynamoDB:ssä N partitioavainta.

## Yhden äänen dedup

Valvo "yksi ääni per käyttäjä" idempotenssiavaimella: `SADD voted:{pollId} {userId}` (tai ehdollinen put). Jos käyttäjä on jo olemassa, pudota tapahtuma ennen inkrementointia. Tee tämä consumerissa, ei clientissä — clientit valehtelevat ja yrittävät uudelleen.

## Haastattelunäkökulma

Haastattelija tutkii, tunnistatko **yhden kuuman avaimen ongelman** ja tartutko puskurointiin + shardaukseen etkä "lisää DB-replikoita" (replikat skaalaavat lukemisia, eivät tätä kirjoitusta). Hyvä: "käytä jonoa ja cachea." Loistava: nimeät **eventual-consistency-kompromissin** — live-luku laahaa todellisuutta sekunnin verran — ja perustelet, että se on ok äänimäärälle mutta *ei* lopulliselle sertifioidulle tulokselle, jonka lasket auktoritatiivisesti uudelleen äänestyksen sulkeuduttua.

**Yleinen ansa:** tietokantatransaktion käyttäminen per ääni "tarkkuuden" vuoksi. Tässä mittakaavassa juuri se sulaa.

## Kompromissit ja virhetilanteet

- **Eventual tally:** shard-summat laahaavat; hyväksyttävää live-laskurille, täsmäytä sulkeutuessa.
- **At-least-once-toimitus:** Kafka voi toimittaa uudelleen — dedup tekee inkrementeistä idempotentteja, muuten lasket kahdesti.
- **Kuuman shardin vinouma (skew):** liian vähän shardeja ja kilpailet edelleen; liian monta ja summaus tulee kalliiksi. 32–128 shardia on tyypillistä.
- **Reiluus/petos:** rate-limitoi per IP/laite; yhden äänen SET on eheysrajasi. Sen menettäminen tarkoittaa vaalihuijausta, ei kaatumista — kiistatta pahempaa.

Miksi puskuroida kirjoitukset

Shardatut laskurit tappavat hotspotin

Yhden äänen dedup

Haastattelunäkökulma

Kompromissit ja virhetilanteet

Aiheeseen liittyvät kysymykset