Hoe verstuur je promocodes naar 1 miljoen gebruikers binnen een kort tijdvenster?

Question

IT Interview Practice · Accepted Answer

Loop nooit over 1 miljoen gebruikers in een request handler — **spreid het werk via een queue**, throttle tot wat elke provider kan verwerken, maak elke verzending **idempotent**, en stuur mislukkingen naar een DLQ om opnieuw te proberen. De API-aanroep zet alleen in de queue; workers doen de trage I/O.

## Architectuur

```text
Admin ─▶ Campaign API ─▶ [job in queue] ─▶ Kafka/SQS ─┐
                                                     ▼
   ┌──────────────── Worker pool (autoscaled) ───────────────┐
   │  claim ─▶ dedup(Redis SETNX) ─▶ rate-limiter ─▶ provider │
   └──────────┬──────────────────────────────┬───────────────┘
              │ ok                            │ fail (5xx/timeout)
              ▼                               ▼
        sent_log (DB)                    Retry (backoff) ─▶ DLQ
```

## Componenten en flow

- **Campaign API** schrijft de campagne weg en zet jobs in de queue — één per gebruiker of per **batch van ~500** om queue-overhead te beperken. De API keert direct terug; de 1 miljoen verzendingen gebeuren achter de queue.
- **Queue (Kafka / SQS)** is de buffer en de *replay*-log. Als workers crashen, blijven berichten staan; er gaat geen werk verloren. Partitioneer op `user_id` zodat de volgorde per gebruiker stabiel blijft.
- **Worker pool** haalt jobs op en schaalt automatisch op basis van queue-lag. Elke worker: (1) reserveert een unieke promocode, (2) controleert een **dedup key** `SETNX sent:{campaign}:{user}` in Redis zodat een opnieuw bezorgd bericht nooit dubbel verzendt, (3) gaat door een **rate limiter** die is afgestemd op het quotum van de provider, (4) roept Email/SMS/Push aan.
- **Rate limiter** is de crux: SendGrid of Twilio zal je throttlen of blacklisten boven hun limiet. Een Redis token bucket per provider begrenst de uitgaande RPS ongeacht hoeveel workers draaien.
- **DLQ** vangt poison messages op na N retries met exponential backoff + jitter, zodat een fout adres nooit de campagne blokkeert.

## Interviewperspectief

De interviewer peilt of je **ontkoppeling en back-pressure** begrijpt. Een "uitstekend" antwoord benoemt de exacte faalmodus: zonder idempotentie levert een at-least-once queue plus een retry op dat gebruikers drie codes krijgen; zonder rate limiter DDoS je jezelf tegen de provider en word je naar nul geknepen. De klassieke valkuil is de fan-out synchroon doen ("gewoon `Promise.all`") — dat houdt connecties bezet, heeft geen retry, en verliest alles bij een deploy.

## Afwegingen en faalmodi

- **At-least-once versus exactly-once**: queues leveren goedkoop at-least-once; je koopt "effectief één keer" met de Redis dedup key, niet met een dure exactly-once broker.
- **Throughput versus providerlimieten**: je kunt eindeloos workers toevoegen, maar het providerquotum is het echte plafond — vraag een quotumverhoging aan of pre-warm vóór de campagne.
- **Faalmodus**: Redis down → verzendingen stallen (fail closed, sla dedup niet over en riskeer geen dubbelingen). Houd een per-campagne teller bij zodat je na een incident kunt hervatten in plaats van herstarten.

Architectuur

Componenten en flow

Interviewperspectief

Afwegingen en faalmodi

Gerelateerde vragen