Jak odešlete promo kódy 1 milionu uživatelů v krátkém časovém okně?

Question

IT Interview Practice · Accepted Answer

Nikdy neprocházejte 1 milion uživatelů ve smyčce uvnitř request handleru — **rozprostřete práci přes frontu**, omezte tempo na to, co každý poskytovatel dokáže přijmout, udělejte každé odeslání **idempotentní** a chybující zprávy směrujte do DLQ pro opakování. Volání API pouze zařadí úlohu do fronty; pomalé I/O provádějí workery.

## 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 a tok

- **Campaign API** zapíše kampaň a zařadí úlohy do fronty — jednu na uživatele nebo na **dávku ~500**, aby se snížila režie fronty. Vrací výsledek okamžitě; oněch 1 milion odeslání probíhá za frontou.
- **Fronta (Kafka / SQS)** je buffer i *replay* log. Pokud workery spadnou, zprávy zůstanou na místě; žádná práce se neztratí. Partitujte podle `user_id`, aby bylo pořadí na uživatele stabilní.
- **Worker pool** vybírá úlohy a autoškáluje podle zpoždění fronty. Každý worker: (1) rezervuje unikátní promo kód, (2) zkontroluje **dedup klíč** `SETNX sent:{campaign}:{user}` v Redisu, aby znovudoručená zpráva nikdy neodeslala kód dvakrát, (3) projde přes **rate limiter** dimenzovaný na kvótu poskytovatele, (4) zavolá Email/SMS/Push.
- **Rate limiter** je jádro věci: SendGrid nebo Twilio vás nad svým limitem začnou omezovat nebo zablokují. Redis token bucket na poskytovatele omezuje odchozí RPS bez ohledu na to, kolik workerů běží.
- **DLQ** zachytí poison messages po N pokusech s exponenciálním backoffem + jitterem, takže špatná adresa nikdy nezablokuje kampaň.

## Pohled z pohovoru

Tazatel zkoumá, zda rozumíte **oddělení (decoupling) a back-pressure**. „Skvělá“ odpověď pojmenuje přesné selhání: bez idempotence znamená at-least-once fronta plus retry, že uživatelé dostanou tři kódy; bez rate limiteru sami DDoSujete poskytovatele a necháte se uškrtit na nulu. Častou pastí je synchronní fan-out („prostě `Promise.all`“) — to blokuje spojení, nemá retry a při deployi vše ztratíte.

## Kompromisy a selhání

- **At-least-once vs exactly-once**: fronty poskytnou at-least-once levně; „efektivně jednou“ si koupíte Redis dedup klíčem, nikoli drahým exactly-once brokerem.
- **Throughput vs limity poskytovatele**: workerů můžete přidávat donekonečna, ale skutečným stropem je kvóta poskytovatele — před kampaní si vyžádejte navýšení kvóty nebo předehřejte spojení.
- **Selhání**: Redis je nedostupný → odesílání se zastaví (fail closed, nepřeskakujte dedup a neriskujte duplicity). Sledujte čítač na kampaň, abyste po incidentu mohli pokračovat, nikoli začínat znovu.

Architektura

Komponenty a tok

Pohled z pohovoru

Kompromisy a selhání

Související otázky