Cum trimiți coduri promoționale către 1 milion de utilizatori într-un interval scurt?

Question

IT Interview Practice · Accepted Answer

Nu itera niciodată peste 1M de utilizatori într-un request handler — **distribuie sarcina printr-o coadă (fan out)**, limitează debitul la ceea ce poate accepta fiecare furnizor, fă fiecare trimitere **idempotentă** și trimite eșecurile într-un DLQ pentru reîncercare. Apelul API doar pune în coadă; workerii fac I/O-ul lent.

## Arhitectură

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

## Componente și flux

- **Campaign API** scrie campania și pune joburi în coadă — unul per utilizator sau per **batch de ~500** pentru a reduce overhead-ul cozii. Răspunde instantaneu; cele 1M de trimiteri se întâmplă în spatele cozii.
- **Coada (Kafka / SQS)** este bufferul și log-ul de *replay*. Dacă workerii cad, mesajele rămân pe loc; niciun cod nu se pierde. Fă partition după `user_id`, astfel încât ordonarea per utilizator să fie stabilă.
- **Worker pool** preia joburile și face autoscale în funcție de lag-ul cozii. Fiecare worker: (1) rezervă un cod promoțional unic, (2) verifică o **cheie de dedup** `SETNX sent:{campaign}:{user}` în Redis, astfel încât un mesaj redistribuit să nu trimită de două ori, (3) trece printr-un **rate limiter** dimensionat pentru cota furnizorului, (4) apelează Email/SMS/Push.
- **Rate limiter-ul** este esența problemei: SendGrid sau Twilio te vor throttla sau pune pe blacklist dacă depășești limita lor. Un token bucket în Redis per furnizor plafonează RPS-ul de ieșire, indiferent de câți workeri rulează.
- **DLQ** prinde mesajele otrăvite (poison messages) după N reîncercări cu exponential backoff + jitter, astfel încât o adresă greșită să nu blocheze niciodată campania.

## Perspectiva de interviu

Intervievatorul verifică dacă înțelegi **decuplarea și back-pressure-ul**. Un răspuns "excelent" numește eșecul exact: fără idempotență, o coadă at-least-once plus o reîncercare înseamnă utilizatori care primesc trei coduri; fără rate limiter, faci self-DDoS pe furnizor și ești throttlat la zero. Capcana obișnuită este fan-out-ul sincron ("pur și simplu `Promise.all`") — asta blochează conexiunile, nu are reîncercare și pierde tot la un deploy.

## Compromisuri și eșecuri

- **At-least-once vs exactly-once**: cozile oferă at-least-once ieftin; cumperi "efectiv o singură dată" cu cheia de dedup din Redis, nu cu un broker exactly-once costisitor.
- **Throughput vs limitele furnizorului**: poți adăuga workeri la nesfârșit, dar cota furnizorului este plafonul real — cere o creștere de cotă sau fă pre-warm înainte de campanie.
- **Eșec**: Redis căzut → trimiterile se blochează (fail closed, nu sări peste dedup riscând dubluri). Ține un contor per campanie, ca să poți relua, nu reporni, după un incident.

Arhitectură

Componente și flux

Perspectiva de interviu

Compromisuri și eșecuri

Întrebări conexe