¿Cómo envías códigos promocionales a 1M de usuarios en una ventana corta de tiempo?

Question

IT Interview Practice · Accepted Answer

Nunca recorras 1M de usuarios dentro de un handler de request — **reparte el trabajo a través de una cola (fan out)**, limita el ritmo a lo que cada proveedor puede aceptar, haz que cada envío sea **idempotente** y enruta los fallos a una DLQ para reintentar. La llamada a la API solo encola; los workers hacen el I/O lento.

## Arquitectura

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

- **Campaign API** escribe la campaña y encola los jobs — uno por usuario o por **lote de ~500** para reducir el overhead de la cola. Devuelve al instante; los 1M de envíos ocurren detrás de la cola.
- **La cola (Kafka / SQS)** es el buffer y el log de *replay*. Si los workers se caen, los mensajes permanecen; no se pierde código. Particiona por `user_id` para que el orden por usuario sea estable.
- **El worker pool** consume los jobs y hace autoscaling según el lag de la cola. Cada worker: (1) reserva un código promocional único, (2) comprueba una **clave de dedup** `SETNX sent:{campaign}:{user}` en Redis para que un mensaje reentregado nunca provoque un doble envío, (3) pasa por un **rate limiter** dimensionado a la cuota del proveedor, (4) llama a Email/SMS/Push.
- **El rate limiter** es el punto clave: SendGrid o Twilio te limitarán o te pondrán en lista negra si superas su límite. Un token bucket de Redis por proveedor topa el RPS de salida sin importar cuántos workers estén corriendo.
- **La DLQ** captura los mensajes envenenados (poison messages) tras N reintentos con backoff exponencial + jitter, de modo que una dirección incorrecta nunca bloquee la campaña.

## Perspectiva de la entrevista

El entrevistador está sondeando si entiendes el **desacoplamiento y la back-pressure**. Una respuesta "excelente" nombra el fallo exacto: sin idempotencia, una cola at-least-once más un reintento equivale a usuarios recibiendo tres códigos; sin un rate limiter, te auto-DDoS al proveedor y te limitan hasta cero. La trampa habitual es hacer el fan-out de forma síncrona ("solo un `Promise.all`") — eso amarra conexiones, no tiene reintentos y lo pierde todo en un deploy.

## Compensaciones y fallos

- **At-least-once vs exactly-once**: las colas dan at-least-once de forma barata; compras el "efectivamente una vez" con la clave de dedup de Redis, no con un broker exactly-once costoso.
- **Throughput vs límites del proveedor**: puedes añadir workers indefinidamente, pero la cuota del proveedor es el verdadero techo — solicita un aumento de cuota o haz pre-warm antes de la campaña.
- **Fallo**: si Redis cae → los envíos se detienen (fail closed, no te saltes el dedup arriesgando duplicados). Lleva un contador por campaña para poder reanudar, no reiniciar, tras un incidente.

Arquitectura

Componentes y flujo

Perspectiva de la entrevista

Compensaciones y fallos

Preguntas relacionadas