Como você envia códigos promocionais para 1M de usuários em uma janela curta?

Question

IT Interview Practice · Accepted Answer

Nunca percorra 1M de usuários em um handler de requisição — **distribua o trabalho através de uma fila (fan out)**, limite a taxa ao que cada provedor consegue aceitar, torne cada envio **idempotente** e roteie falhas para uma DLQ para retry. A chamada de API apenas enfileira; os workers fazem o I/O lento.

## Arquitetura

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

## Componentes e fluxo

- **Campaign API** grava a campanha e enfileira os jobs — um por usuário ou por **lote de ~500** para reduzir o overhead da fila. Ela retorna instantaneamente; os 1M de envios acontecem por trás da fila.
- **Fila (Kafka / SQS)** é o buffer e o log de *replay*. Se os workers caírem, as mensagens permanecem; nenhum trabalho é perdido. Particione por `user_id` para que a ordenação por usuário seja estável.
- **Worker pool** puxa os jobs e faz autoscaling conforme o atraso (lag) da fila. Cada worker: (1) reserva um código promocional único, (2) verifica uma **chave de dedup** `SETNX sent:{campaign}:{user}` no Redis para que uma mensagem reentregue nunca envie em duplicidade, (3) passa por um **rate limiter** dimensionado para a cota do provedor, (4) chama Email/SMS/Push.
- **Rate limiter** é o ponto crucial: SendGrid ou Twilio vão te throttlar ou colocar na blacklist acima do limite deles. Um token bucket no Redis por provedor limita o RPS de saída independentemente de quantos workers estejam rodando.
- **DLQ** captura mensagens venenosas (poison messages) após N retries com backoff exponencial + jitter, para que um endereço inválido nunca bloqueie a campanha.

## Perspectiva de entrevista

O entrevistador está sondando se você entende **desacoplamento e back-pressure**. Uma resposta "excelente" nomeia a falha exata: sem idempotência, uma fila at-least-once mais um retry resulta em usuários recebendo três códigos; sem um rate limiter, você faz um self-DDoS no provedor e é throttlado até zero. A armadilha comum é fazer o fan-out de forma síncrona ("só um `Promise.all`") — isso prende conexões, não tem retry e perde tudo num deploy.

## Trade-offs e falhas

- **At-least-once vs exactly-once**: filas oferecem at-least-once de forma barata; você compra o "efetivamente uma vez" com a chave de dedup no Redis, não com um broker exactly-once caro.
- **Throughput vs limites do provedor**: você pode adicionar workers para sempre, mas a cota do provedor é o teto real — solicite um aumento de cota ou faça o pré-aquecimento antes da campanha.
- **Falha**: Redis fora do ar → envios travam (fail closed, não pule o dedup arriscando duplicatas). Rastreie um contador por campanha para poder retomar, não reiniciar, após um incidente.

Arquitetura

Componentes e fluxo

Perspectiva de entrevista

Trade-offs e falhas

Perguntas relacionadas