Kif timmaniġġja 5M vot f'10 minuti fuq skala?

Question

IT Interview Practice · Accepted Answer

Tiktibx kull vot direttament f'row ta' database — **agħmel buffer tal-writes, ippartizzjona l-counters, u aċċetta tally eventwali**. 5M vot f'10 minuti huma ~8,300 vot/sekonda bħala medja, bi spikes ħafna ogħla (mument ta' TV live jista' jimmultiplika dan bi 10x). It-trick huwa li tibdel update ta' row wieħed jaħraq f'ħafna increments indipendenti u paralleli.

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

## Għaliex tagħmel buffer tal-writes

Queue bħal **Kafka** tiddekja l-inġestjoni mit-tallying. Il-kitba tal-klijent hija append irħis; jekk il-consumers jaqgħu lura waqt spike, l-events jistennew fil-log minflok jgħarrqu d-DB. Kafka jagħti wkoll **replay** — jekk consumer jaqa', tirriproċessa mill-aħħar offset committjat mingħajr ma titlef voti.

## Sharded counters joqtlu l-hotspot

Jekk kull vot għal "Option A" jagħmel `UPDATE counter SET n=n+1 WHERE id='A'`, dak ir-row wieħed isir bottleneck ta' lock-contention — eluf ta' transactions jissereljaw fuq row wieħed. Minflok, aqsam kull għażla f'**N shard rows** (`A:0 … A:63`). Kull increment jolqot shard każwali, allura l-writes jinfirxu fuq N row u jaħdmu b'mod parallel. It-total muri huwa `SUM(shards)`, ikkalkulat kull sekonda jew tnejn minn aggregator. F'Redis dan huwa sempliċiment N `INCR` keys; f'DynamoDB, N partition keys.

## One-vote dedup

Infforza "vot wieħed għal kull utent" b'idempotency key: `SADD voted:{pollId} {userId}` (jew conditional put). Jekk l-utent diġà jeżisti, warrab l-event qabel ma żżid. Agħmel dan fil-consumer, mhux fil-klijent — il-klijenti jigdbu u jerġgħu jippruvaw.

## Perspettiva tal-intervista

L-intervistatur qed jgħarbel jekk tirrikonoxxix il-**problema tas-single-hot-key** u taqbad buffering + sharding minflok "żid aktar DB replicas" (r-replicas jiskalaw reads, mhux din il-kitba). Tajjeb: "uża queue u cache." Eċċellenti: issemmi t-**trade-off tal-eventual-consistency** — in-numru live jkun lura mir-realtà b'sekonda — u targumenta li dan huwa tajjeb għal għadd ta' voti imma *mhux* għar-riżultat finali ċċertifikat, li tikkalkula mill-ġdid b'mod awtorevoli wara li jagħlaq il-poll.

**Nassa komuni:** li tuża database transaction għal kull vot għall-"preċiżjoni." Fuq din l-iskala dik hija l-ħaġa li tinħall.

## Trade-offs u modi ta' fallimenti

- **Tally eventwali:** is-somom tal-shards jaqgħu lura; aċċettabbli għal counter live, irrikonċilja mal-għeluq.
- **Delivery at-least-once:** Kafka jista' jerġa' jibgħat — id-dedup jagħmel l-increments idempotenti, inkella tgħodd darbtejn.
- **Skew ta' hot shard:** ftit wisq shards u għadek tikkonkorri; wisq u s-somma ssir għalja. 32–128 shards huma tipiċi.
- **Ġustizzja/frodi:** rate-limit għal kull IP/apparat; is-SET tal-vot wieħed huwa l-fruntiera tal-integrità tiegħek. Li titilfu jfisser ballot stuffing, mhux crash — forsi agħar.

Għaliex tagħmel buffer tal-writes

Sharded counters joqtlu l-hotspot

One-vote dedup

Perspettiva tal-intervista

Trade-offs u modi ta' fallimenti

Mistoqsijiet relatati