คุณจะจัดการ 5M vote ใน 10 นาทีที่ scale ระดับใหญ่อย่างไร?

Question

IT Interview Practice · Accepted Answer

อย่าเขียนแต่ละ vote ลง database row ตรง ๆ — **buffer การเขียน, shard counter และยอมรับ tally แบบ eventual** 5M vote ใน 10 นาทีคือเฉลี่ยราว 8,300 vote/วินาที โดยมี spike สูงกว่านั้นมาก (ช่วง TV สดสามารถทำให้พุ่ง 10 เท่า) เคล็ดลับคือเปลี่ยนการ update row เดียวที่ร้อนให้เป็น increment แบบขนานที่อิสระต่อกันจำนวนมาก

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

## ทำไมต้อง buffer การเขียน

queue อย่าง **Kafka** decouple การ ingest ออกจากการนับ การเขียนของ client เป็นเพียง append ราคาถูก ถ้า consumer ตามไม่ทันช่วง spike event จะรออยู่ใน log แทนที่จะถล่ม DB Kafka ยังให้ **replay** — ถ้า consumer crash คุณ reprocess จาก offset ที่ commit ล่าสุดโดยไม่เสีย vote

## Sharded counter กำจัด hotspot

ถ้าทุก vote ของ "Option A" ทำ `UPDATE counter SET n=n+1 WHERE id='A'` row เดียวนั้นกลายเป็น bottleneck ของ lock-contention — transaction หลายพันรายการ serialize บน row เดียว แทนที่จะเป็นแบบนั้น ให้แยกแต่ละ option เป็น **N shard row** (`A:0 … A:63`) แต่ละ increment ชน shard สุ่มหนึ่งอัน การเขียนจึงกระจายข้าม N row และรันแบบขนาน ยอดที่แสดงคือ `SUM(shards)` คำนวณทุกหนึ่งหรือสองวินาทีโดย aggregator ใน Redis นี่คือแค่ N key ที่ `INCR` ใน DynamoDB คือ N partition key

## Dedup หนึ่งคนหนึ่ง vote

บังคับ "หนึ่ง vote ต่อผู้ใช้" ด้วย idempotency key: `SADD voted:{pollId} {userId}` (หรือ conditional put) ถ้าผู้ใช้มีอยู่แล้ว ให้ drop event ก่อน increment ทำสิ่งนี้ใน consumer ไม่ใช่ที่ client — client โกหกและ retry

## มุมมองการสัมภาษณ์

ผู้สัมภาษณ์กำลังจี้ว่าคุณตระหนักถึง **ปัญหา single-hot-key** และไขว่คว้าหา buffering + sharding แทน "เพิ่ม DB replica" หรือไม่ (replica scale การอ่าน ไม่ใช่การเขียนแบบนี้) ดี: "ใช้ queue และ cache" เยี่ยม: คุณระบุ **ข้อแลกเปลี่ยน eventual-consistency** — ตัวเลขสดล่าช้ากว่าความจริงหนึ่งวินาที — และโต้แย้งว่านั่นโอเคสำหรับจำนวน vote แต่ *ไม่โอเค* สำหรับผลลัพธ์รับรองสุดท้าย ซึ่งคุณคำนวณใหม่แบบ authoritative หลังปิดโหวต

**กับดักที่พบบ่อย:** ใช้ database transaction ต่อ vote เพื่อ "ความแม่นยำ" ที่ scale นี้นั่นคือสิ่งที่จะละลาย

## ข้อแลกเปลี่ยน & โหมด failure

- **Tally แบบ eventual:** ผลรวม shard ล่าช้า ยอมรับได้สำหรับ counter สด กระทบยอดตอนปิด
- **การส่งแบบ at-least-once:** Kafka อาจส่งซ้ำ — dedup ทำให้ increment เป็น idempotent ไม่งั้นคุณจะนับซ้ำสอง
- **Hot shard skew:** shard น้อยเกินไปยังคง contend มากเกินไปการ sum จะแพง 32–128 shard เป็นค่าปกติ
- **ความเป็นธรรม/การโกง:** rate-limit ต่อ IP/device SET หนึ่ง vote คือขอบเขตความสมบูรณ์ของคุณ การเสียมันไปหมายถึงการยัด ballot ไม่ใช่การ crash — เถียงได้ว่าแย่กว่า

ทำไมต้อง buffer การเขียน

Sharded counter กำจัด hotspot

Dedup หนึ่งคนหนึ่ง vote

มุมมองการสัมภาษณ์

ข้อแลกเปลี่ยน & โหมด failure

คำถามที่เกี่ยวข้อง