Bagaimana Anda menangani 5 juta vote dalam 10 menit pada skala besar?

Question

IT Interview Practice · Accepted Answer

Jangan menulis setiap vote langsung ke baris database — **buffer write, shard counter, dan terima tally yang eventual**. 5 juta vote dalam 10 menit adalah rata-rata ~8.300 vote/detik, dengan lonjakan jauh lebih tinggi (momen TV langsung bisa 10x-nya). Triknya adalah mengubah update satu baris panas menjadi banyak increment independen dan 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
```

## Mengapa mem-buffer write

Sebuah queue seperti **Kafka** memisahkan ingesti dari penghitungan (tally). Write dari klien adalah append yang murah; jika consumer tertinggal saat lonjakan, event menunggu di log alih-alih membanjiri DB. Kafka juga memberi **replay** — jika consumer crash, Anda memproses ulang dari offset terakhir yang di-commit tanpa kehilangan vote.

## Sharded counter mematikan hotspot

Jika setiap vote untuk "Option A" melakukan `UPDATE counter SET n=n+1 WHERE id='A'`, satu baris itu menjadi bottleneck lock-contention — ribuan transaksi menserialisasi pada satu baris. Sebagai gantinya, pecah setiap opsi menjadi **N shard rows** (`A:0 … A:63`). Setiap increment mengenai shard acak, sehingga write menyebar ke N baris dan berjalan paralel. Total yang ditampilkan adalah `SUM(shards)`, dihitung setiap satu-dua detik oleh aggregator. Di Redis ini hanyalah N key `INCR`; di DynamoDB, N partition key.

## Dedup satu-vote

Tegakkan "satu vote per pengguna" dengan idempotency key: `SADD voted:{pollId} {userId}` (atau conditional put). Jika pengguna sudah ada, buang event sebelum increment. Lakukan ini di consumer, bukan di klien — klien berbohong dan me-retry.

## Perspektif wawancara

Pewawancara menyelidiki apakah Anda mengenali **masalah single-hot-key** dan meraih buffering + sharding alih-alih "tambah saja replica DB" (replica menskala baca, bukan write ini). Baik: "gunakan queue dan cache." Hebat: Anda menyebut **trade-off eventual-consistency** — angka langsung tertinggal dari realita sedetik — dan berargumen itu baik untuk hitungan vote tetapi *tidak* untuk hasil final tersertifikasi, yang Anda hitung ulang secara otoritatif setelah polling ditutup.

**Jebakan umum:** menggunakan transaksi database per vote demi "akurasi". Pada skala ini itulah yang meleleh.

## Trade-off & mode kegagalan

- **Tally eventual:** jumlah shard tertinggal; dapat diterima untuk counter langsung, rekonsiliasi saat penutupan.
- **Pengiriman at-least-once:** Kafka bisa mengirim ulang — dedup membuat increment idempotent, jika tidak Anda menghitung ganda.
- **Skew shard panas:** terlalu sedikit shard dan Anda masih berkontensi; terlalu banyak dan penjumlahan jadi mahal. 32–128 shard adalah umum.
- **Keadilan/kecurangan:** rate-limit per IP/perangkat; SET satu-vote adalah batas integritas Anda. Kehilangannya berarti ballot stuffing, bukan crash — bisa dibilang lebih buruk.

Mengapa mem-buffer write

Sharded counter mematikan hotspot

Dedup satu-vote

Perspektif wawancara

Trade-off & mode kegagalan

Pertanyaan terkait