Hvordan sender du promo-koder til 1M brugere inden for et kort tidsrum?

Question

IT Interview Practice · Accepted Answer

Loop aldrig over 1M brugere i en request-handler — **fan ud gennem en queue**, throttle til det hver provider kan modtage, gør hver afsendelse **idempotent**, og send fejl til en DLQ til retry. API-kaldet står kun for at enqueue; workers udfører den langsomme I/O.

## Arkitektur

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

## Komponenter og flow

- **Campaign API** skriver kampagnen og enqueuer jobs — ét pr. bruger eller pr. **batch af ~500** for at reducere queue-overhead. Den returnerer øjeblikkeligt; de 1M afsendelser sker bag queuen.
- **Queue (Kafka / SQS)** er både buffer og *replay*-log. Hvis workers crasher, bliver beskeder liggende; ingen kode går tabt. Partitionér efter `user_id`, så rækkefølgen pr. bruger er stabil.
- **Worker pool** trækker jobs og autoscaler på queue-lag. Hver worker: (1) reserverer en unik promo-kode, (2) tjekker en **dedup-nøgle** `SETNX sent:{campaign}:{user}` i Redis, så en gen-leveret besked aldrig sender to gange, (3) passerer gennem en **rate limiter** dimensioneret til providerens quota, (4) kalder Email/SMS/Push.
- **Rate limiter** er kernen: SendGrid eller Twilio vil throttle eller blackliste dig over deres grænse. En Redis token bucket pr. provider begrænser udgående RPS uanset hvor mange workers der kører.
- **DLQ** fanger poison-beskeder efter N retries med eksponentiel backoff + jitter, så en dårlig adresse aldrig blokerer kampagnen.

## Interview-perspektiv

Intervieweren undersøger, om du forstår **decoupling og back-pressure**. Et "fremragende" svar navngiver den præcise fejl: uden idempotens giver en at-least-once queue plus en retry, at brugere får tre koder; uden en rate limiter self-DDoS'er du provideren og bliver throttlet ned til nul. Den almindelige fælde er at lave fan-out synkront ("bare `Promise.all`") — det binder connections, har ingen retry og mister alt ved en deploy.

## Trade-offs og fejl

- **At-least-once vs exactly-once**: queues giver at-least-once billigt; du køber "effectively once" med Redis dedup-nøglen, ikke med en dyr exactly-once broker.
- **Throughput vs provider-grænser**: du kan tilføje workers i det uendelige, men providerens quota er det reelle loft — bed om en quota-forhøjelse eller pre-warm før kampagnen.
- **Fejl**: Redis nede → afsendelser stalder (fail closed, spring ikke dedup over og risikér dubletter). Hold en tæller pr. kampagne, så du kan genoptage frem for at genstarte efter en hændelse.

Arkitektur

Komponenter og flow

Interview-perspektiv

Trade-offs og fejl

Relaterede spørgsmål