Как отправить промокоды 1 млн пользователей за короткое окно времени?

Question

IT Interview Practice · Accepted Answer

Никогда не перебирайте 1 млн пользователей в обработчике запроса — **разложите работу через очередь (fan-out)**, ограничивайте темп тем, что готов принять каждый провайдер, делайте каждую отправку **идемпотентной** и направляйте сбои в DLQ для повторов. Вызов API только ставит задачи в очередь; медленный 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** записывает кампанию и ставит задачи в очередь — по одной на пользователя или на **батч из ~500**, чтобы срезать накладные расходы очереди. Он возвращает ответ мгновенно; сама отправка 1 млн сообщений происходит за очередью.
- **Очередь (Kafka / SQS)** — это и буфер, и лог для *повторного проигрывания (replay)*. Если воркеры падают, сообщения остаются на месте; ничего не теряется. Партиционируйте по `user_id`, чтобы порядок для одного пользователя оставался стабильным.
- **Пул воркеров** забирает задачи и автомасштабируется по отставанию очереди (queue lag). Каждый воркер: (1) резервирует уникальный промокод, (2) проверяет **ключ дедупликации** `SETNX sent:{campaign}:{user}` в Redis, чтобы повторно доставленное сообщение никогда не отправлялось дважды, (3) проходит через **rate limiter**, рассчитанный на квоту провайдера, (4) вызывает Email/SMS/Push.
- **Rate limiter** — это ключевой момент: SendGrid или Twilio начнут троттлить или заблокируют вас при превышении их лимитов. Token bucket в Redis на каждого провайдера ограничивает исходящий RPS вне зависимости от того, сколько воркеров запущено.
- **DLQ** ловит «ядовитые» сообщения после N повторов с экспоненциальным backoff и jitter, так что один плохой адрес никогда не блокирует всю кампанию.

## Взгляд с точки зрения интервью

Интервьюер проверяет, понимаете ли вы **декуплинг и back-pressure**. «Отличный» ответ называет конкретный сбой: без идемпотентности очередь at-least-once плюс повтор означают, что пользователи получают по три кода; без rate limiter вы устраиваете self-DDoS провайдеру и получаете троттлинг до нуля. Классическая ловушка — делать fan-out синхронно («просто `Promise.all`»): это занимает соединения, не имеет повторов и теряет всё при деплое.

## Компромиссы и отказы

- **At-least-once против exactly-once**: очереди дёшево дают at-least-once; «фактически один раз» вы покупаете за счёт ключа дедупликации в Redis, а не дорогого exactly-once брокера.
- **Throughput против лимитов провайдера**: воркеров можно добавлять бесконечно, но квота провайдера — это реальный потолок; запросите повышение квоты или прогрейте её заранее до старта кампании.
- **Отказ**: упал Redis → отправки останавливаются (fail closed, не пропускайте дедупликацию и не рискуйте дублями). Ведите счётчик по кампании, чтобы после инцидента можно было продолжить, а не начинать заново.

Архитектура

Компоненты и поток

Взгляд с точки зрения интервью

Компромиссы и отказы

Похожие вопросы