How do you send promo codes to 1M users in a short window?

Question

IT Interview Practice · Accepted Answer

Never loop over 1M users in a request handler — **fan out through a queue**, throttle to what each provider can accept, make every send **idempotent**, and route failures to a DLQ for retry. The API call only enqueues; workers do the slow I/O.

## Architecture

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

## Components and flow

- **Campaign API** writes the campaign and enqueues jobs — one per user or per **batch of ~500** to cut queue overhead. It returns instantly; the 1M sends happen behind the queue.
- **Queue (Kafka / SQS)** is the buffer and the *replay* log. If workers crash, messages stay put; no code is lost. Partition by `user_id` so ordering per user is stable.
- **Worker pool** pulls jobs and autoscales on queue lag. Each worker: (1) reserves a unique promo code, (2) checks a **dedup key** `SETNX sent:{campaign}:{user}` in Redis so a redelivered message never double-sends, (3) passes through a **rate limiter** sized to the provider's quota, (4) calls Email/SMS/Push.
- **Rate limiter** is the crux: SendGrid or Twilio will throttle or blacklist you above their limit. A Redis token bucket per provider caps outbound RPS regardless of how many workers run.
- **DLQ** catches poison messages after N retries with exponential backoff + jitter, so a bad address never blocks the campaign.

## Interview perspective

The interviewer is probing whether you understand **decoupling and back-pressure**. A "great" answer names the exact failure: without idempotency, an at-least-once queue plus a retry equals users getting three codes; without a rate limiter, you self-DDoS the provider and get throttled to zero. The common trap is doing the fan-out synchronously ("just `Promise.all`") — that ties up connections, has no retry, and loses everything on a deploy.

## Trade-offs and failure

- **At-least-once vs exactly-once**: queues give at-least-once cheaply; you buy "effectively once" with the Redis dedup key, not with an expensive exactly-once broker.
- **Throughput vs provider limits**: you can add workers forever, but the provider quota is the real ceiling — request a quota bump or pre-warm before the campaign.
- **Failure**: Redis down → sends stall (fail closed, don't skip dedup and risk doubles). Track a per-campaign counter so you can resume, not restart, after an incident.

Architecture

Components and flow

Interview perspective

Trade-offs and failure

Related questions