Kepiye sampeyan nangani 5 yuta swara sajrone 10 menit ing skala gedhe?

Question

IT Interview Practice · Accepted Answer

Aja nulis saben swara langsung menyang row database — **buffer tulisan, shard counter, lan tampa tally sing eventual**. 5 yuta swara sajrone 10 menit yaiku ~8.300 swara/detik rata-rata, kanthi lonjakan sing luwih dhuwur (momen TV langsung bisa nggawe 10x kuwi). Trik-e yaiku ngowahi update siji-row sing panas dadi akeh increment mandiri sing paralel.

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

## Kenapa kudu nge-buffer tulisan

Antrian kaya **Kafka** misahake ingesti saka tallying. Tulisan klien iku append sing murah; yen consumer keri sajrone lonjakan, event ngenteni ing log tinimbang ngluwihi kapasitas DB. Kafka uga menehi **replay** — yen consumer crash, sampeyan proses maneh saka offset sing dikomit pungkasan tanpa ilang swara.

## Sharded counter ngmatèni hotspot

Yen saben swara kanggo "Option A" nglakoni `UPDATE counter SET n=n+1 WHERE id='A'`, siji row kuwi dadi bottleneck lock-contention — ewonan transaksi nyerialake ing siji row. Malah, bagi saben opsi dadi **N shard row** (`A:0 … A:63`). Saben increment ndemek shard acak, mula tulisan nyebar ing N row lan mlaku paralel. Total sing ditampilake yaiku `SUM(shards)`, diitung saben detik utawa loro dening aggregator. Ing Redis iki mung N key `INCR`; ing DynamoDB, N partition key.

## Dedup siji-swara

Tegakake "siji swara saben pangguna" nganggo idempotency key: `SADD voted:{pollId} {userId}` (utawa conditional put). Yen pangguna wis ana, buwang event sadurunge nambahi increment. Lakonana iki ing consumer, dudu ing klien — klien ngapusi lan nyoba maneh.

## Sudut pandang wawancara

Pewawancara nyoba niteni apa sampeyan ngerteni **masalah single-hot-key** lan njangkau buffering + sharding tinimbang "tambah luwih akeh replika DB" (replika nyekala pamaca, dudu tulisan iki). Apik: "nganggo antrian lan cache." Apik banget: sampeyan nyebutake **trade-off eventual-consistency** — angka langsung keri saka kasunyatan sadetik — lan mbantah yen iku ora apa-apa kanggo cacahan swara nanging *ora* kanggo asil final sing disertifikasi, sing sampeyan itung maneh kanthi otoritatif sawise poll tutup.

**Jebakan umum:** nganggo transaksi database saben swara kanggo "akurasi". Ing skala iki, kuwi sing bakal lebur.

## Trade-off lan mode kegagalan

- **Tally eventual:** jumlah shard keri; bisa ditampa kanggo counter langsung, rekonsiliasi nalika nutup.
- **Pangiriman at-least-once:** Kafka bisa ngirim maneh — dedup ndadekake increment idempotent, yen ora sampeyan bakal ngetung pindho.
- **Skew hot shard:** kekurangan shard sampeyan isih contention; kakehan lan njumlah dadi larang. 32–128 shard iku umum.
- **Keadilan/penipuan:** rate-limit saben IP/piranti; SET siji-swara iku wates integritas sampeyan. Ngilangi kuwi tegese ballot stuffing, dudu crash — bisa uga luwih ala.

Kenapa kudu nge-buffer tulisan

Sharded counter ngmatèni hotspot

Dedup siji-swara

Sudut pandang wawancara

Trade-off lan mode kegagalan

Pitakon sing gegandhengan