Hvordan sender du kampanjekoder til 1M brukere i et kort tidsvindu?

Question

IT Interview Practice · Accepted Answer

Aldri loop over 1M brukere i en request-handler — **spre arbeidet ut via en kø**, strup ned til det hver leverandør kan ta imot, gjør hver sending **idempotent**, og rut feil til en DLQ for retry. API-kallet gjør bare enqueue; workerne gjør den trege I/O-en.

## Arkitektur

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

## Komponenter og flyt

- **Campaign API** skriver kampanjen og legger jobber i kø — én per bruker eller per **batch på ~500** for å kutte kø-overhead. Den returnerer umiddelbart; de 1M sendingene skjer bak køen.
- **Kø (Kafka / SQS)** er bufferet og *replay*-loggen. Hvis workere krasjer, blir meldingene liggende; ingen kode går tapt. Partisjoner på `user_id` slik at rekkefølgen per bruker er stabil.
- **Worker-pool** trekker jobber og autoskalerer på queue lag. Hver worker: (1) reserverer en unik kampanjekode, (2) sjekker en **dedup-nøkkel** `SETNX sent:{campaign}:{user}` i Redis slik at en redelivered melding aldri dobbeltsender, (3) går gjennom en **rate limiter** dimensjonert til leverandørens kvote, (4) kaller Email/SMS/Push.
- **Rate limiter** er kjernen: SendGrid eller Twilio vil strupe eller svarteliste deg over grensen deres. En Redis token bucket per leverandør begrenser utgående RPS uansett hvor mange workere som kjører.
- **DLQ** fanger poison-meldinger etter N retries med eksponentiell backoff + jitter, slik at en dårlig adresse aldri blokkerer kampanjen.

## Intervjuperspektiv

Intervjueren undersøker om du forstår **avkobling og back-pressure**. Et "utmerket" svar navngir den nøyaktige feilen: uten idempotens gir en at-least-once-kø pluss en retry at brukere får tre koder; uten en rate limiter gjør du en self-DDoS på leverandøren og blir strupet til null. Den vanlige fellen er å gjøre fan-out synkront ("bare `Promise.all`") — det binder opp connections, har ingen retry, og mister alt ved en deploy.

## Avveininger og feil

- **At-least-once vs exactly-once**: køer gir at-least-once billig; du kjøper "effektivt én gang" med Redis dedup-nøkkelen, ikke med en dyr exactly-once-broker.
- **Throughput vs leverandørgrenser**: du kan legge til workere i det uendelige, men leverandørkvoten er det reelle taket — be om en kvoteøkning eller pre-warm før kampanjen.
- **Feil**: Redis nede → sendinger stopper (fail closed, ikke hopp over dedup og risiker dobler). Spor en teller per kampanje slik at du kan gjenoppta, ikke restarte, etter en hendelse.

Arkitektur

Komponenter og flyt

Intervjuperspektiv

Avveininger og feil

Relaterte spørsmål