Xử lý 5 triệu lượt vote trong 10 phút ở quy mô lớn thế nào?

Question

IT Interview Practice · Accepted Answer

Đừng ghi mỗi phiếu thẳng vào một dòng database — **hãy buffer (đệm) write, shard counter, và chấp nhận tally (kiểm phiếu) eventual**. 5 triệu phiếu trong 10 phút là ~8.300 phiếu/giây trung bình, với đỉnh cao hơn nhiều (một khoảnh khắc truyền hình trực tiếp có thể gấp 10 lần). Mẹo là biến một update vào một dòng nóng thành nhiều increment độc lập, song song.

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

## Vì sao phải buffer write

Một queue như **Kafka** tách rời việc nhận phiếu khỏi việc kiểm phiếu. Write từ client chỉ là một thao tác append rẻ; nếu consumer tụt lại trong lúc đỉnh tải, event nằm chờ trong log thay vì làm ngập DB. Kafka còn cho **replay** — nếu consumer crash, bạn xử lý lại từ offset đã commit gần nhất mà không mất phiếu.

## Sharded counter triệt tiêu hotspot

Nếu mọi phiếu cho "Option A" đều chạy `UPDATE counter SET n=n+1 WHERE id='A'`, dòng đơn đó thành nút thắt tranh chấp lock — hàng nghìn transaction serialize trên một dòng. Thay vào đó, chia mỗi lựa chọn thành **N dòng shard** (`A:0 … A:63`). Mỗi increment đánh vào một shard ngẫu nhiên, nên write trải ra N dòng và chạy song song. Tổng hiển thị là `SUM(shards)`, được aggregator tính mỗi một hai giây. Trong Redis đây chỉ là N key `INCR`; trong DynamoDB là N partition key.

## Dedup một-phiếu

Bắt buộc "một phiếu mỗi user" bằng một idempotency key: `SADD voted:{pollId} {userId}` (hoặc conditional put). Nếu user đã tồn tại, bỏ event trước khi increment. Làm việc này ở consumer, không phải client — client hay nói dối và retry.

## Góc nhìn phỏng vấn

Người phỏng vấn dò xem bạn có nhận ra **vấn đề single-hot-key** và với tới buffering + sharding thay vì "thêm DB replica" (replica scale read, không scale write này). Khá: "dùng queue và cache." Xuất sắc: bạn gọi tên **đánh đổi eventual-consistency** — con số live trễ thực tế một giây — và lập luận rằng điều đó ổn cho đếm phiếu nhưng *không* ổn cho kết quả chính thức, thứ bạn tính lại một cách authoritative sau khi đóng poll.

**Bẫy thường gặp:** dùng một database transaction mỗi phiếu để "chính xác." Ở quy mô này đó chính là thứ làm hệ thống chảy nhựa.

## Đánh đổi & kịch bản hỏng

- **Eventual tally:** tổng shard trễ; chấp nhận được cho counter live, đối soát lại khi đóng.
- **At-least-once delivery:** Kafka có thể gửi lại — dedup làm increment idempotent, nếu không bạn đếm trùng.
- **Hot shard skew:** quá ít shard vẫn tranh chấp; quá nhiều thì summing tốn kém. 32–128 shard là điển hình.
- **Công bằng/gian lận:** rate-limit theo IP/thiết bị; SET one-vote là ranh giới toàn vẹn. Mất nó nghĩa là nhồi phiếu, không phải crash — có thể còn tệ hơn.

Vì sao phải buffer write

Sharded counter triệt tiêu hotspot

Dedup một-phiếu

Góc nhìn phỏng vấn

Đánh đổi & kịch bản hỏng

Câu hỏi liên quan