Hur skickar du kampanjkoder till 1M användare inom ett kort tidsfönster?

Question

IT Interview Practice · Accepted Answer

Loopa aldrig över 1M användare i en request-hanterare — **fan-outa genom en kö**, strypa till vad varje leverantör klarar av att ta emot, gör varje utskick **idempotent** och dirigera fel till en DLQ för omförsök. API-anropet köar bara upp jobbet; workers utför den långsamma I/O:n.

## 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 och flöde

- **Campaign API** skriver kampanjen och köar upp jobb — ett per användare eller per **batch om ~500** för att minska köns overhead. Det svarar direkt; de 1M utskicken sker bakom kön.
- **Kön (Kafka / SQS)** är bufferten och *replay*-loggen. Om workers kraschar ligger meddelandena kvar; ingen kod går förlorad. Partitionera på `user_id` så att ordningen per användare är stabil.
- **Worker pool** hämtar jobb och autoskalar på köns lag. Varje worker: (1) reserverar en unik kampanjkod, (2) kontrollerar en **dedup-nyckel** `SETNX sent:{campaign}:{user}` i Redis så att ett omlevererat meddelande aldrig skickar dubbelt, (3) passerar en **rate limiter** dimensionerad efter leverantörens kvot, (4) anropar Email/SMS/Push.
- **Rate limiter** är kärnan: SendGrid eller Twilio kommer att strypa eller svartlista dig över deras gräns. En Redis token bucket per leverantör begränsar utgående RPS oavsett hur många workers som körs.
- **DLQ** fångar poison messages efter N omförsök med exponentiell backoff + jitter, så att en felaktig adress aldrig blockerar kampanjen.

## Intervjuperspektiv

Intervjuaren undersöker om du förstår **decoupling och back-pressure**. Ett "utmärkt" svar namnger det exakta felet: utan idempotens innebär en at-least-once-kö plus ett omförsök att användare får tre koder; utan en rate limiter DDoS:ar du dig själv mot leverantören och blir strypt till noll. Den vanliga fällan är att göra fan-out synkront ("bara `Promise.all`") — det binder upp anslutningar, saknar omförsök och förlorar allt vid en deploy.

## Avvägningar och fel

- **At-least-once vs exactly-once**: köer ger at-least-once billigt; du köper "effectively once" med Redis dedup-nyckeln, inte med en dyr exactly-once-broker.
- **Throughput vs leverantörsgränser**: du kan lägga till workers hur länge som helst, men leverantörens kvot är det verkliga taket — begär en kvothöjning eller värm upp i förväg innan kampanjen.
- **Fel**: Redis nere → utskick stannar (fail closed, hoppa inte över dedup och riskera dubbletter). Håll en räknare per kampanj så att du kan återuppta, inte starta om, efter en incident.

Arkitektur

Komponenter och flöde

Intervjuperspektiv

Avvägningar och fel

Relaterade frågor