Come invii codici promozionali a 1M di utenti in una finestra temporale ristretta?

Question

IT Interview Practice · Accepted Answer

Non iterare mai su 1M di utenti dentro un request handler: **distribuisci il carico tramite una coda**, applica un throttling pari a ciò che ogni provider è in grado di accettare, rendi ogni invio **idempotente** e instrada i fallimenti verso una DLQ per il retry. La chiamata API si limita ad accodare; i worker svolgono l'I/O lento.

## Architettura

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

## Componenti e flusso

- **Campaign API** scrive la campagna e accoda i job, uno per utente o per **batch di ~500** per ridurre l'overhead della coda. Ritorna istantaneamente; gli 1M di invii avvengono dietro la coda.
- **Coda (Kafka / SQS)** è il buffer e il log di *replay*. Se i worker vanno in crash, i messaggi restano al loro posto; nessun lavoro va perso. Partiziona per `user_id` così che l'ordinamento per utente resti stabile.
- **Worker pool** preleva i job e fa autoscaling in base al lag della coda. Ogni worker: (1) riserva un codice promozionale univoco, (2) verifica una **dedup key** `SETNX sent:{campaign}:{user}` in Redis così che un messaggio riconsegnato non provochi mai un doppio invio, (3) passa attraverso un **rate limiter** dimensionato sulla quota del provider, (4) chiama Email/SMS/Push.
- **Rate limiter** è il punto cruciale: SendGrid o Twilio ti applicheranno throttling o ti metteranno in blacklist se superi i loro limiti. Un token bucket in Redis per ciascun provider limita gli RPS in uscita indipendentemente da quanti worker girano.
- **DLQ** cattura i messaggi poison dopo N retry con exponential backoff + jitter, così che un indirizzo errato non blocchi mai la campagna.

## Prospettiva del colloquio

L'intervistatore sta verificando se hai compreso il **decoupling e la back-pressure**. Una risposta "eccellente" nomina il fallimento esatto: senza idempotenza, una coda at-least-once più un retry equivalgono a utenti che ricevono tre codici; senza rate limiter, fai auto-DDoS al provider e ti ritrovi con throttling a zero. La trappola comune è eseguire il fan-out in modo sincrono ("basta un `Promise.all`"): questo occupa le connessioni, non prevede retry e perde tutto a ogni deploy.

## Compromessi e modalità di guasto

- **At-least-once vs exactly-once**: le code offrono at-least-once a basso costo; ottieni un "effettivamente una volta" con la dedup key in Redis, non con un costoso broker exactly-once.
- **Throughput vs limiti del provider**: puoi aggiungere worker all'infinito, ma la quota del provider è il vero tetto: richiedi un aumento di quota o fai pre-warming prima della campagna.
- **Guasto**: Redis down → gli invii si bloccano (fail closed, non saltare la dedup rischiando i doppioni). Tieni un contatore per campagna così da poter riprendere, e non riavviare, dopo un incidente.

Architettura

Componenti e flusso

Prospettiva del colloquio

Compromessi e modalità di guasto

Domande correlate