Kako slati promotivne kodove za 1 milijun korisnika u kratkom vremenskom prozoru?

Question

IT Interview Practice · Accepted Answer

Nikada ne prolazite kroz 1 milijun korisnika unutar obrađivača zahtjeva — **raspršite posao kroz queue**, ograničite (throttle) na ono što svaki pružatelj usluge može prihvatiti, učinite svako slanje **idempotentnim** i preusmjerite neuspjehe u DLQ za ponovni pokušaj. API poziv samo stavlja u queue; workeri obavljaju spori I/O.

## Arhitektura

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

## Komponente i tok

- **Campaign API** zapisuje kampanju i stavlja poslove u queue — jedan po korisniku ili po **grupi od ~500** kako bi se smanjio queue overhead. Vraća odgovor trenutno; 1 milijun slanja događa se iza queuea.
- **Queue (Kafka / SQS)** je buffer i *replay* log. Ako se workeri sruše, poruke ostaju na mjestu; ništa se ne gubi. Particionirajte po `user_id` kako bi redoslijed po korisniku bio stabilan.
- **Worker pool** povlači poslove i automatski skalira na temelju queue laga. Svaki worker: (1) rezervira jedinstveni promotivni kod, (2) provjerava **dedup ključ** `SETNX sent:{campaign}:{user}` u Redisu tako da ponovno isporučena poruka nikada ne pošalje dvaput, (3) prolazi kroz **rate limiter** dimenzioniran prema kvoti pružatelja usluge, (4) poziva Email/SMS/Push.
- **Rate limiter** je ključ: SendGrid ili Twilio će vas ograničiti ili staviti na crnu listu iznad njihovog limita. Redis token bucket po pružatelju ograničava izlazni RPS bez obzira na to koliko workera radi.
- **DLQ** hvata problematične poruke nakon N pokušaja s eksponencijalnim backoffom + jitterom, tako da loša adresa nikada ne blokira kampanju.

## Perspektiva intervjua

Ispitivač provjerava razumijete li **decoupling i back-pressure**. "Odličan" odgovor imenuje točan neuspjeh: bez idempotentnosti, at-least-once queue plus retry znači da korisnici dobivaju tri koda; bez rate limitera sami sebi radite DDoS na pružatelja i budete ograničeni na nulu. Uobičajena zamka je sinkroni fan-out ("samo `Promise.all`") — to zauzima veze, nema retry i sve gubi pri deployu.

## Kompromisi i neuspjesi

- **At-least-once vs exactly-once**: queuei jeftino daju at-least-once; "praktički jednom" kupujete Redis dedup ključem, a ne skupim exactly-once brokerom.
- **Throughput vs limiti pružatelja**: workere možete dodavati beskonačno, ali kvota pružatelja je pravi strop — zatražite povećanje kvote ili ju pripremite (pre-warm) prije kampanje.
- **Neuspjeh**: Redis nedostupan → slanja se zaustavljaju (fail closed, ne preskačite dedup i riskirajte duplikate). Pratite brojač po kampanji kako biste nakon incidenta mogli nastaviti, a ne krenuti ispočetka.

Arhitektura

Komponente i tok

Perspektiva intervjua

Kompromisi i neuspjesi

Povezana pitanja