Kako obvladate 5 milijonov glasov v 10 minutah v obsegu (at scale)?

Question

IT Interview Practice · Accepted Answer

Ne zapisujte vsakega glasu naravnost v vrstico podatkovne baze — **medpomnite zapise, razdelite (shard) števce in sprejmite eventualni izračun (tally)**. 5M glasov v 10 minutah je povprečno ~8.300 glasov/s, s konicami precej višjimi (trenutek v živi TV oddaji lahko to 10-kratno poveča). Trik je spremeniti vroč posodobitev ene vrstice v mnogo neodvisnih, vzporednih povečanj.

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

## Zakaj medpomniti zapise

Vrsta, kot je **Kafka**, razklopi zajem (ingestion) od izračunavanja. Zapis odjemalca je poceni dodajanje (append); če consumerji zaostanejo med konico, dogodki čakajo v dnevniku, namesto da preplavijo DB. Kafka daje tudi **replay** — če se consumer sesuje, ponovno obdelate od zadnjega potrjenega odmika (offset), ne da bi izgubili glasove.

## Razdeljeni (sharded) števci ubijejo vročo točko

Če vsak glas za "Opcijo A" izvede `UPDATE counter SET n=n+1 WHERE id='A'`, ta ena vrstica postane ozko grlo tekmovanja za zaklep — tisoči transakcij se serializirajo na eni vrstici. Namesto tega razdelite vsako opcijo v **N shard vrstic** (`A:0 … A:63`). Vsako povečanje zadene naključni shard, tako da se zapisi razporedijo čez N vrstic in tečejo vzporedno. Prikazani skupek je `SUM(shards)`, ki ga agregator izračuna vsako sekundo ali dve. V Redisu je to le N `INCR` ključev; v DynamoDB N particijskih ključev.

## Dedup enega glasu

Uveljavite "en glas na uporabnika" z idempotenčnim ključem: `SADD voted:{pollId} {userId}` (ali pogojni put). Če uporabnik že obstaja, zavrzite dogodek pred povečanjem. To naredite v consumerju, ne v odjemalcu — odjemalci lažejo in ponavljajo.

## Pogled s stališča razgovora

Izpraševalec preverja, ali prepoznate **problem enega vročega ključa (single-hot-key)** in posežete po medpomnjenju + shardingu namesto "dodaj več DB replik" (replike skalirajo branja, ne teh zapisov). Dobro: "uporabi vrsto in cache." Odlično: poimenujete **kompromis eventualne konsistentnosti** — živa številka za sekundo zaostaja za realnostjo — in utemeljite, da je to v redu za štetje glasov, *ne pa* za končni certificirani rezultat, ki ga avtoritativno preračunate po zaprtju glasovanja.

**Pogosta past:** uporaba transakcije podatkovne baze na glas zaradi "natančnosti". V tem obsegu je to prav tisto, kar se stopi.

## Kompromisi in načini odpovedi

- **Eventualni izračun:** vsote shardov zaostajajo; sprejemljivo za živ števec, uskladite ob zaprtju.
- **At-least-once dostava:** Kafka lahko ponovno dostavi — dedup naredi povečanja idempotentna, sicer štejete dvojno.
- **Neenakomernost vročih shardov (hot shard skew):** premalo shardov in še vedno tekmujete; preveč in seštevanje postane drago. 32–128 shardov je tipično.
- **Poštenost/goljufija:** rate-limit na IP/napravo; SET za en glas je vaša integritetna meja. Izguba tega pomeni polnjenje glasovnice (ballot stuffing), ne sesutja — kar je verjetno slabše.

Zakaj medpomniti zapise

Razdeljeni (sharded) števci ubijejo vročo točko

Dedup enega glasu

Pogled s stališča razgovora

Kompromisi in načini odpovedi

Povezana vprašanja