Wie versendest du Promo-Codes an 1 Mio. Nutzer in einem kurzen Zeitfenster?

Question

IT Interview Practice · Accepted Answer

Iteriere in einem Request-Handler niemals über 1 Mio. Nutzer - **verteile die Last über eine Queue (fan out)**, drossle auf das, was jeder Provider akzeptiert, mache jeden Versand **idempotent** und leite Fehler zur erneuten Verarbeitung in eine DLQ. Der API-Aufruf reiht nur ein; die Worker erledigen die langsame I/O.

## Architektur

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

## Komponenten und Ablauf

- **Campaign API** schreibt die Kampagne und reiht Jobs ein - einen pro Nutzer oder pro **Batch von ~500**, um den Queue-Overhead zu senken. Sie antwortet sofort; die 1 Mio. Sendungen laufen hinter der Queue ab.
- **Queue (Kafka / SQS)** ist der Puffer und das *Replay*-Log. Stürzen Worker ab, bleiben die Nachrichten erhalten; kein Code geht verloren. Partitioniere nach `user_id`, damit die Reihenfolge pro Nutzer stabil bleibt.
- **Worker pool** zieht Jobs und skaliert automatisch anhand des Queue-Lags. Jeder Worker: (1) reserviert einen eindeutigen Promo-Code, (2) prüft einen **Dedup-Key** `SETNX sent:{campaign}:{user}` in Redis, damit eine erneut zugestellte Nachricht nie doppelt sendet, (3) durchläuft einen **Rate Limiter**, der auf das Kontingent des Providers dimensioniert ist, (4) ruft E-Mail/SMS/Push auf.
- **Rate Limiter** ist der Knackpunkt: SendGrid oder Twilio drosseln oder sperren dich oberhalb ihres Limits. Ein Redis-Token-Bucket pro Provider deckelt die ausgehende RPS, unabhängig davon, wie viele Worker laufen.
- **DLQ** fängt Poison-Messages nach N Retries mit Exponential Backoff + Jitter, damit eine fehlerhafte Adresse die Kampagne nie blockiert.

## Interview-Perspektive

Der Interviewer prüft, ob du **Entkopplung und Back-Pressure** verstehst. Eine hervorragende Antwort benennt das konkrete Versagen: ohne Idempotenz führt eine At-least-once-Queue plus Retry dazu, dass Nutzer drei Codes bekommen; ohne Rate Limiter DDoSt du den Provider selbst und wirst auf null gedrosselt. Die häufige Falle ist ein synchrones Fan-out ("einfach `Promise.all`") - das bindet Verbindungen, hat kein Retry und verliert bei einem Deploy alles.

## Trade-offs und Fehlerfälle

- **At-least-once vs. exactly-once**: Queues liefern At-least-once günstig; "effektiv einmal" erkaufst du dir mit dem Redis-Dedup-Key, nicht mit einem teuren Exactly-once-Broker.
- **Throughput vs. Provider-Limits**: Du kannst endlos Worker hinzufügen, aber das Provider-Kontingent ist die reale Obergrenze - fordere vor der Kampagne eine Kontingenterhöhung an oder wärme vor.
- **Fehlerfall**: Redis ausgefallen → Sendungen stocken (fail closed, überspringe die Deduplizierung nicht und riskiere keine Doppelsendungen). Führe einen Zähler pro Kampagne, damit du nach einem Vorfall fortsetzen statt neu starten kannst.

Architektur

Komponenten und Ablauf

Interview-Perspektive

Trade-offs und Fehlerfälle

Ähnliche Fragen