How do you handle 5M votes in 10 minutes at scale?

Question

IT Interview Practice · Accepted Answer

Don't write each vote straight to a database row — **buffer writes, shard the counters, and accept eventual tally**. 5M votes in 10 minutes is ~8,300 votes/sec average, with spikes far higher (a live TV moment can 10x that). The trick is to turn a hot single-row update into many independent, parallel increments.

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

## Why buffer the writes

A queue like **Kafka** decouples ingestion from tallying. The client write is a cheap append; if consumers fall behind during a spike, events wait in the log instead of overwhelming the DB. Kafka also gives **replay** — if a consumer crashes, you reprocess from the last committed offset without losing votes.

## Sharded counters kill the hotspot

If every vote for "Option A" does `UPDATE counter SET n=n+1 WHERE id='A'`, that single row becomes a lock-contention bottleneck — thousands of transactions serialize on one row. Instead, split each option into **N shard rows** (`A:0 … A:63`). Each increment hits a random shard, so writes spread across N rows and run in parallel. The displayed total is `SUM(shards)`, computed every second or two by an aggregator. In Redis this is just N `INCR` keys; in DynamoDB, N partition keys.

## One-vote dedup

Enforce "one vote per user" with an idempotency key: `SADD voted:{pollId} {userId}` (or a conditional put). If the user already exists, drop the event before incrementing. Do this in the consumer, not the client — clients lie and retry.

## Interview perspective

The interviewer is probing whether you recognize the **single-hot-key problem** and reach for buffering + sharding rather than "add more DB replicas" (replicas scale reads, not this write). Good: "use a queue and a cache." Great: you name the **eventual-consistency trade-off** — the live number lags reality by a second — and argue that's fine for a vote count but *not* for the final certified result, which you recompute authoritatively after the poll closes.

**Common trap:** using a database transaction per vote for "accuracy." At this scale that's the thing that melts.

## Trade-offs & failure modes

- **Eventual tally:** shard sums lag; acceptable for a live counter, reconcile at close.
- **At-least-once delivery:** Kafka may redeliver — dedup makes increments idempotent, otherwise you double-count.
- **Hot shard skew:** too few shards and you still contend; too many and summing gets expensive. 32–128 shards is typical.
- **Fairness/fraud:** rate-limit per IP/device; the one-vote SET is your integrity boundary. Losing it means ballot stuffing, not a crash — arguably worse.

Why buffer the writes

Sharded counters kill the hotspot

One-vote dedup

Interview perspective

Trade-offs & failure modes

Related questions