Bagaimana anda mengendalikan 5J undian dalam 10 minit pada skala besar?

Question

IT Interview Practice · Accepted Answer

Jangan tulis setiap undi terus ke satu baris database — **tampan penulisan, shard kaunter, dan terima kiraan eventual**. 5J undi dalam 10 minit ialah ~8,300 undi/saat purata, dengan lonjakan jauh lebih tinggi (satu detik TV langsung boleh 10x itu). Silapnya ialah menukar kemas kini satu baris panas menjadi banyak penambahan bebas dan selari.

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

## Mengapa menampan penulisan

Sebuah queue seperti **Kafka** men-decouple pengambilan (ingestion) daripada pengiraan (tallying). Penulisan client ialah append yang murah; jika consumer ketinggalan semasa lonjakan, peristiwa menunggu di dalam log dan bukannya menenggelamkan DB. Kafka juga memberi **replay** — jika consumer crash, anda memproses semula dari offset terakhir yang di-commit tanpa kehilangan undi.

## Sharded counter membunuh hotspot

Jika setiap undi untuk "Option A" melakukan `UPDATE counter SET n=n+1 WHERE id='A'`, satu baris itu menjadi kesesakan pertikaian lock — beribu transaction men-serialize pada satu baris. Sebaliknya, pecahkan setiap pilihan menjadi **N shard rows** (`A:0 … A:63`). Setiap penambahan mengenai shard rawak, jadi penulisan tersebar merentas N baris dan berjalan selari. Jumlah yang dipaparkan ialah `SUM(shards)`, dikira setiap saat atau dua oleh aggregator. Dalam Redis ini hanyalah N key `INCR`; dalam DynamoDB, N partition key.

## Dedup satu undi

Kuatkuasakan "satu undi bagi setiap pengguna" dengan idempotency key: `SADD voted:{pollId} {userId}` (atau conditional put). Jika pengguna sudah wujud, gugurkan peristiwa sebelum menambah. Lakukan ini di consumer, bukan client — client menipu dan mencuba semula.

## Perspektif temu duga

Penemu duga sedang menyiasat sama ada anda mengenali **masalah single-hot-key** dan menggapai buffering + sharding dan bukannya "tambah lebih banyak DB replica" (replica menskala bacaan, bukan penulisan ini). Baik: "guna queue dan cache." Hebat: anda menyebut **pertukaran eventual-consistency** — nombor langsung ketinggalan realiti sesaat — dan berhujah itu tidak mengapa untuk kiraan undi tetapi *bukan* untuk keputusan disahkan (certified) akhir, yang anda kira semula secara berautoriti selepas undian ditutup.

**Perangkap biasa:** menggunakan database transaction bagi setiap undi demi "ketepatan." Pada skala ini itulah perkara yang cair.

## Pertukaran & mod kegagalan

- **Kiraan eventual:** jumlah shard ketinggalan; boleh diterima untuk kaunter langsung, rekonsiliasi pada penutupan.
- **Penghantaran at-least-once:** Kafka mungkin menghantar semula — dedup menjadikan penambahan idempotent, jika tidak anda mengira dua kali.
- **Kepincangan shard panas (hot shard skew):** terlalu sedikit shard dan anda masih bertikai; terlalu banyak dan penjumlahan menjadi mahal. 32–128 shard adalah tipikal.
- **Keadilan/penipuan:** rate-limit setiap IP/peranti; SET satu undi ialah sempadan integriti anda. Kehilangannya bermakna pemenuhan undi (ballot stuffing), bukan crash — boleh dikatakan lebih teruk.

Mengapa menampan penulisan

Sharded counter membunuh hotspot

Dedup satu undi

Perspektif temu duga

Pertukaran & mod kegagalan

Soalan berkaitan