Jak wysłać kody promocyjne do 1 mln użytkowników w krótkim oknie czasowym?

Question

IT Interview Practice · Accepted Answer

Nigdy nie iteruj po 1 mln użytkowników w handlerze żądania — **rozprowadź pracę przez kolejkę (fan out)**, ogranicz tempo (throttle) do tego, co każdy dostawca jest w stanie przyjąć, uczyń każdą wysyłkę **idempotentną** i kieruj błędy do DLQ w celu ponowienia. Wywołanie API jedynie umieszcza zadanie w kolejce; workery wykonują wolne operacje I/O.

## Architektura

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

## Komponenty i przepływ

- **Campaign API** zapisuje kampanię i umieszcza zadania w kolejce — jedno na użytkownika lub na **partię ~500**, aby zmniejszyć narzut kolejki. Zwraca odpowiedź natychmiast; wysyłka do 1 mln odbywa się za kolejką.
- **Kolejka (Kafka / SQS)** jest buforem i logiem *replay*. Jeśli workery ulegną awarii, wiadomości pozostają na miejscu; żadne zadanie nie przepada. Partycjonuj po `user_id`, aby uporządkowanie per użytkownik było stabilne.
- **Pula workerów** pobiera zadania i skaluje się automatycznie w oparciu o zaległości (lag) w kolejce. Każdy worker: (1) rezerwuje unikatowy kod promocyjny, (2) sprawdza **klucz dedupikacji** `SETNX sent:{campaign}:{user}` w Redis, aby ponownie dostarczona wiadomość nigdy nie wysłała kodu dwukrotnie, (3) przechodzi przez **rate limiter** dobrany do limitu dostawcy, (4) wywołuje Email/SMS/Push.
- **Rate limiter** jest sednem: SendGrid lub Twilio ograniczą lub zablokują cię po przekroczeniu ich limitu. Token bucket w Redis per dostawca ogranicza wychodzące RPS niezależnie od liczby uruchomionych workerów.
- **DLQ** przechwytuje trujące wiadomości po N ponowieniach z wykładniczym backoffem i jitterem, tak aby zły adres nigdy nie blokował kampanii.

## Perspektywa rozmowy kwalifikacyjnej

Rozmówca sprawdza, czy rozumiesz **odseparowanie (decoupling) i back-pressure**. „Świetna” odpowiedź nazywa konkretną awarię: bez idempotentności kolejka at-least-once plus ponowienie oznacza, że użytkownicy dostają trzy kody; bez rate limitera sam wykonasz DDoS na dostawcę i zostaniesz ograniczony do zera. Częstą pułapką jest wykonywanie fan-outu synchronicznie („po prostu `Promise.all`") — to blokuje połączenia, nie ma ponowień i traci wszystko przy deployu.

## Kompromisy i awarie

- **At-least-once vs exactly-once**: kolejki dają at-least-once tanio; „efektywnie raz" kupujesz kluczem dedupikacji w Redis, a nie kosztownym brokerem exactly-once.
- **Throughput vs limity dostawcy**: workery możesz dodawać w nieskończoność, ale limit dostawcy jest realnym sufitem — poproś o podniesienie limitu lub rozgrzej (pre-warm) go przed kampanią.
- **Awaria**: Redis padł → wysyłki się zatrzymują (fail closed, nie pomijaj dedupikacji i nie ryzykuj dubli). Prowadź licznik per kampania, aby po incydencie wznowić, a nie restartować.

Architektura

Komponenty i przepływ

Perspektywa rozmowy kwalifikacyjnej

Kompromisy i awarie

Powiązane pytania