คุณจะออกแบบ scheduler สำหรับงานตั้งเวลา 10M รายการอย่างไร?

Question

IT Interview Practice · Accepted Answer

เก็บ task ไว้ใน **time-bucketed / priority queue** ที่ใช้เวลาครบกำหนดเป็น key, poll เฉพาะ task ที่ครบกำหนด *ตอนนี้* แล้วส่งให้ worker ที่ idempotent ด้วยการส่งแบบ **at-least-once** อย่าสแกน 10M row ทุก tick — ทำ index ตาม fire time เพื่อให้แต่ละ poll แตะเฉพาะสิ่งที่ครบกำหนด

## สถาปัตยกรรม

```text
API ─▶ Task store (DB/Redis ZSET, score = due_ts)  ── 10M tasks, sharded
             │
     Poller (leader per partition) ── ZPOPMIN due<=now ──▶ Ready queue (Kafka)
             │ leader election (etcd/ZK)                       │
             ▼                                                 ▼
     other pollers idle/standby                       Worker pool (idempotent)
                                                        └─ ack ✔ / retry ✖ ─▶ DLQ
```

## องค์ประกอบและการไหลของงาน

- **Task store ที่ index ตาม fire time**: Redis sorted set (`ZADD tasks score=due_ts`) หรือตาราง DB ที่ index บน `(run_at)` `ZPOPMIN`/`ZRANGEBYSCORE now` ดึงเฉพาะ task ที่ครบกำหนดวินาทีนี้ — O(log n) ไม่ใช่ table scan การ **sharding/partitioning** ตาม task-id กระจาย 10M task ข้าม node เพื่อไม่ให้ store ใด store หนึ่งร้อน
- **Poller พร้อม leader election**: แต่ละ partition มี poller ที่ active หนึ่งตัว เลือกผ่าน etcd/ZooKeeper ส่วน standby เข้ามาแทนเมื่อล้มเหลว การมี leader หนึ่งตัวต่อ partition หลีกเลี่ยงการที่ poller สองตัว dispatch task เดียวกัน ขณะที่ partitioning ทำให้ throughput สูงอยู่
- **Ready queue (Kafka)**: task ที่ครบกำหนดถูก enqueue โดย decouple *การจัดตาราง* ออกจาก *การ execute* worker scale อิสระจาก poller
- **Idempotent worker** execute แล้ว **ack** เพราะการส่งเป็น at-least-once task อาจรันสองครั้ง (poller crash หลัง dispatch ก่อนทำเครื่องหมายว่าเสร็จ) — ดังนั้นงานเองต้อง idempotent โดยใช้ `task_id` เป็น key ไม่งั้นคุณจะเรียกเก็บเงินลูกค้าซ้ำสอง failure จะ retry ด้วย backoff แล้วไปตกที่ DLQ

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

ผู้สัมภาษณ์จี้สองเรื่อง: **การ lookup เวลาที่มีประสิทธิภาพ** และ **exactly-once vs at-least-once** "ดี" คือ cron loop วนตาราง "เยี่ยม" คือ sorted-set index บวกกับการยอมรับตามตรงว่า distributed exactly-once นั้นไม่สามารถทำได้จริง ดังนั้นคุณเลือก **at-least-once + idempotent worker** กับดักคลาสสิก: การพึ่ง scheduler node เดียว — มันเป็น SPOF และเพดาน throughput อีกกับดัก: poll หยาบเกินไป (ทุกนาที) ในขณะที่ task ต้องการความแม่นยำระดับวินาที หรือละเอียดเกินไปจนถล่ม store

## ข้อแลกเปลี่ยนและ failure

- **ความแม่นยำ vs load**: tick 1 วินาทีให้ความแม่นยำระดับวินาทีแต่ poll มากขึ้น จัด bucket task เป็น sub-queue ระดับนาทีแล้วระดับวินาทีเพื่อลดต้นทุนการสแกน (แนวทาง "timing wheel" / hashed-wheel ที่ Kafka และ Quartz ใช้)
- **At-least-once vs exactly-once**: คุณไม่สามารถได้ exactly-once จริงข้ามขอบเขต crash ได้ idempotency key ทำให้การ execute ซ้ำไม่เป็นอันตราย — เป็นการแลกเปลี่ยนที่ถูกต้อง
- **Failure**: ถ้า poller ตายกลาง dispatch, leader election จะเลื่อน standby ขึ้นและ task ที่ยังไม่ ack จะถูกส่งใหม่ — ไม่มีอะไรสูญหาย บางอันอาจซ้ำ ระวัง **clock skew** ข้าม node (NTP) ไม่งั้น task fire เร็ว/ช้า และจำกัด retry เพื่อไม่ให้ task ที่ล้มเหลวถาวรวนไม่รู้จบ — ส่งไป DLQ เพื่อตรวจสอบ

สถาปัตยกรรม

องค์ประกอบและการไหลของงาน

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

ข้อแลกเปลี่ยนและ failure

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