Làm sao gửi mã khuyến mãi cho 1 triệu user trong thời gian ngắn?

Question

IT Interview Practice · Accepted Answer

Đừng bao giờ lặp qua 1 triệu user ngay trong request handler — hãy **fan-out qua queue**, throttle theo mức mỗi provider chịu được, làm mỗi lần gửi **idempotent**, và đẩy lỗi vào DLQ để retry. Lời gọi API chỉ enqueue; worker mới làm phần I/O chậm.

## Kiến trúc

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

## Thành phần và luồng

- **Campaign API** ghi campaign và enqueue job — mỗi user một job, hoặc gộp **batch ~500** để giảm overhead của queue. Nó trả về ngay; 1 triệu lượt gửi diễn ra phía sau queue.
- **Queue (Kafka / SQS)** là buffer và cũng là log *replay*. Worker chết thì message vẫn nằm đó; không mất việc nào. Partition theo `user_id` để thứ tự cho từng user ổn định.
- **Worker pool** kéo job và autoscale theo độ trễ (lag) của queue. Mỗi worker: (1) giữ một mã khuyến mãi duy nhất, (2) kiểm tra **dedup key** `SETNX sent:{campaign}:{user}` trong Redis để message bị gửi lại không gửi trùng, (3) đi qua **rate limiter** đặt theo quota của provider, (4) gọi Email/SMS/Push.
- **Rate limiter** là điểm mấu chốt: SendGrid hay Twilio sẽ throttle hoặc chặn bạn nếu vượt giới hạn. Một token bucket trên Redis cho mỗi provider giới hạn RPS đầu ra bất kể chạy bao nhiêu worker.
- **DLQ** hứng message hỏng sau N lần retry với exponential backoff + jitter, để một địa chỉ sai không chặn cả campaign.

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

Người phỏng vấn dò xem bạn có hiểu **decoupling và back-pressure** không. Câu trả lời "xuất sắc" chỉ đúng tên kịch bản hỏng: thiếu idempotency, queue at-least-once cộng một lần retry là user nhận ba mã; thiếu rate limiter, bạn tự DDoS provider rồi bị throttle về không. Bẫy thường gặp là fan-out đồng bộ ("cứ `Promise.all`") — nó chiếm hết connection, không có retry, và mất sạch khi deploy.

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

- **At-least-once vs exactly-once**: queue cho at-least-once với chi phí rẻ; bạn mua "hiệu quả một lần" bằng dedup key trên Redis, không phải bằng một broker exactly-once đắt đỏ.
- **Throughput vs giới hạn provider**: thêm worker bao nhiêu cũng được, nhưng quota provider mới là trần thật — xin nâng quota hoặc pre-warm trước campaign.
- **Kịch bản hỏng**: Redis chết → dừng gửi (fail closed, đừng bỏ dedup mà liều gửi trùng). Giữ một counter cho mỗi campaign để có thể tiếp tục (resume), không phải chạy lại từ đầu, sau sự cố.

Kiến trúc

Thành phần và luồng

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

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

Câu hỏi liên quan