Kako pošljete promocijske kode 1 milijonu uporabnikov v kratkem časovnem oknu?

Question

IT Interview Practice · Accepted Answer

Nikoli ne iterirajte čez 1 milijon uporabnikov znotraj obravnave zahteve — **razpršite (fan out) prek vrste (queue)**, omejite hitrost na tisto, kar posamezni ponudnik lahko sprejme, poskrbite, da je vsako pošiljanje **idempotentno**, in usmerite napake v DLQ za ponovni poskus. Klic API le uvrsti opravilo v vrsto; delavci (workers) opravijo počasni 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 in potek

- **Campaign API** zapiše kampanjo in uvrsti opravila v vrsto — eno na uporabnika ali na **paket (batch) ~500** za zmanjšanje režije vrste. Vrne se takoj; milijon pošiljanj se zgodi za vrsto.
- **Vrsta (Kafka / SQS)** je medpomnilnik (buffer) in *replay* dnevnik (log). Če se delavci sesujejo, sporočila ostanejo na mestu; noben kos dela se ne izgubi. Particionirajte po `user_id`, tako da je vrstni red na uporabnika stabilen.
- **Worker pool** poteguje opravila in samodejno skalira glede na zaostanek (lag) vrste. Vsak delavec: (1) rezervira unikatno promocijsko kodo, (2) preveri **dedup ključ** `SETNX sent:{campaign}:{user}` v Redisu, da ponovno dostavljeno sporočilo nikoli ne pošlje dvakrat, (3) prehaja skozi **rate limiter**, dimenzioniran glede na kvoto ponudnika, (4) pokliče Email/SMS/Push.
- **Rate limiter** je bistvo: SendGrid ali Twilio vas bosta omejila (throttle) ali uvrstila na črno listo nad svojo mejo. Redis token bucket na ponudnika omeji odhodni RPS ne glede na to, koliko delavcev teče.
- **DLQ** ujame zastrupljena (poison) sporočila po N ponovnih poskusih z eksponentnim odmikom (backoff) + jitter, tako da napačen naslov nikoli ne blokira kampanje.

## Pogled s stališča razgovora

Izpraševalec preverja, ali razumete **razklopitev (decoupling) in protipritisk (back-pressure)**. "Odličen" odgovor poimenuje natančno napako: brez idempotence at-least-once vrsta plus ponovni poskus pomeni, da uporabniki dobijo tri kode; brez rate limiterja sami sebe DDoS-nete pri ponudniku in vas omeji na nič. Pogosta past je izvajanje fan-outa sinhrono ("samo `Promise.all`") — to zasede povezave, nima ponovnih poskusov in vse izgubi ob deployu.

## Kompromisi in odpovedi

- **At-least-once proti exactly-once**: vrste poceni dajo at-least-once; "dejansko enkrat" (effectively once) kupite z Redis dedup ključem, ne z dragim exactly-once posrednikom (broker).
- **Throughput proti mejam ponudnika**: delavce lahko dodajate v nedogled, a kvota ponudnika je pravi strop — zaprosite za dvig kvote ali predogrejte (pre-warm) pred kampanjo.
- **Odpoved**: Redis pade → pošiljanja se ustavijo (fail closed, ne preskočite dedupa in ne tvegajte dvojnikov). Sledite števcu na kampanjo, da lahko po incidentu nadaljujete (resume), ne pa ponovno zaženete.

Arhitektura

Komponente in potek

Pogled s stališča razgovora

Kompromisi in odpovedi

Povezana vprašanja