คุณจะส่งโปรโมโค้ดให้ผู้ใช้ 1 ล้านคนภายในช่วงเวลาสั้น ๆ ได้อย่างไร?

Question

IT Interview Practice · Accepted Answer

อย่าวนลูปผู้ใช้ 1 ล้านคนภายใน request handler เด็ดขาด — ให้ **กระจายงานผ่าน queue (fan out)** ควบคุมอัตราการส่ง (throttle) ให้พอดีกับที่แต่ละ provider รับได้ ทำให้ทุกการส่งเป็น **idempotent** และส่ง failure ไปที่ DLQ เพื่อ retry การเรียก API เพียงแค่ enqueue เท่านั้น ส่วน worker เป็นผู้ทำงาน I/O ที่ช้า

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

```text
Admin ─▶ Campaign API ─▶ [enqueue job] ─▶ Kafka/SQS ─┐
                                                     ▼
   ┌──────────────── Worker pool (autoscaled) ───────────────┐
   │  claim ─▶ dedup(Redis SETNX) ─▶ rate-limiter ─▶ provider │
   └──────────┬──────────────────────────────┬───────────────┘
              │ ok                            │ fail (5xx/timeout)
              ▼                               ▼
        sent_log (DB)                    Retry (backoff) ─▶ DLQ
```

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

- **Campaign API** เขียนข้อมูล campaign และ enqueue job — หนึ่ง job ต่อหนึ่งผู้ใช้ หรือต่อหนึ่ง **batch ประมาณ 500 ราย** เพื่อลด overhead ของ queue มันจะ return ทันที ส่วนการส่ง 1 ล้านครั้งเกิดขึ้นเบื้องหลัง queue
- **Queue (Kafka / SQS)** ทำหน้าที่เป็น buffer และเป็น log สำหรับ *replay* ถ้า worker crash ข้อความยังคงอยู่ ไม่มีงานสูญหาย แบ่ง partition ด้วย `user_id` เพื่อให้ลำดับต่อผู้ใช้คงที่
- **Worker pool** ดึง job มาทำและ autoscale ตาม queue lag แต่ละ worker: (1) จองโปรโมโค้ดที่ไม่ซ้ำ (2) ตรวจ **dedup key** `SETNX sent:{campaign}:{user}` ใน Redis เพื่อไม่ให้ข้อความที่ถูกส่งซ้ำ (redelivered) ทำการส่งซ้ำสอง (3) ผ่าน **rate limiter** ที่ปรับขนาดตาม quota ของ provider (4) เรียก Email/SMS/Push
- **Rate limiter** คือหัวใจ: SendGrid หรือ Twilio จะ throttle หรือ blacklist คุณเมื่อเกิน limit ของเขา Redis token bucket ต่อ provider จำกัด RPS ขาออกไม่ว่าจะมี worker กี่ตัวก็ตาม
- **DLQ** รองรับ poison message หลังจาก retry N ครั้งด้วย exponential backoff + jitter ทำให้ที่อยู่เสียหนึ่งรายไม่บล็อกทั้ง campaign

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

ผู้สัมภาษณ์กำลังตรวจสอบว่าคุณเข้าใจ **decoupling และ back-pressure** หรือไม่ คำตอบที่ "เยี่ยม" จะระบุจุด failure ได้ชัดเจน: ถ้าไม่มี idempotency queue แบบ at-least-once บวกกับ retry จะทำให้ผู้ใช้ได้รับโค้ดสามครั้ง ถ้าไม่มี rate limiter คุณจะ DDoS ตัวเองใส่ provider จนถูก throttle เหลือศูนย์ กับดักที่พบบ่อยคือทำ fan-out แบบ synchronous ("แค่ `Promise.all`") — ซึ่งจะยึด connection ไว้ ไม่มี retry และสูญเสียทุกอย่างเมื่อ deploy

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

- **At-least-once vs exactly-once**: queue ให้ at-least-once ได้ราคาถูก คุณซื้อ "effectively once" ด้วย Redis dedup key ไม่ใช่ด้วย broker แบบ exactly-once ที่แพง
- **Throughput vs limit ของ provider**: คุณเพิ่ม worker ได้ไม่จำกัด แต่ quota ของ provider คือเพดานจริง — ขอเพิ่ม quota หรือ pre-warm ก่อน campaign
- **Failure**: Redis ล่ม → การส่งค้าง (fail closed อย่าข้าม dedup แล้วเสี่ยงส่งซ้ำ) ติดตาม counter ต่อ campaign เพื่อให้ resume ต่อได้ ไม่ใช่ restart ใหม่หลังเกิดเหตุ

สถาปัตยกรรม

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

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

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

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