Kif tibgħat promo codes lil 1M utent f'window qasira?

Question

IT Interview Practice · Accepted Answer

Qatt m'għandek tagħmel loop fuq 1M utent ġo request handler — **iferrex permezz ta' queue**, ikkontrolla r-rata għal dak li kull provider jista' jaċċetta, agħmel kull send **idempotenti**, u dawwar il-fallimenti lejn DLQ għal retry. Is-sejħa tal-API biss iddaħħal fil-queue; il-workers jagħmlu l-I/O bil-mod.

## Arkitettura

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

## Komponenti u fluss

- **Campaign API** tikteb il-kampanja u ddaħħal il-jobs fil-queue — wieħed għal kull utent jew għal kull **batch ta' ~500** biex jitnaqqas l-overhead tal-queue. Tirritorna mill-ewwel; l-1M sends iseħħu wara l-queue.
- **Queue (Kafka / SQS)** hija l-buffer u l-log ta' *replay*. Jekk il-workers jaqgħu, il-messaġġi jibqgħu fejn huma; ebda kodiċi ma jintilef. Ippartizzjona bi `user_id` biex l-ordni għal kull utent tibqa' stabbli.
- **Worker pool** tiġbed il-jobs u tagħmel autoscale skont il-lag tal-queue. Kull worker: (1) jirriżerva promo code uniku, (2) jiċċekkja **dedup key** `SETNX sent:{campaign}:{user}` f'Redis biex messaġġ mibgħut mill-ġdid qatt ma jibgħat darbtejn, (3) jgħaddi minn **rate limiter** iddimensjonat għall-kwota tal-provider, (4) isejjaħ Email/SMS/Push.
- **Rate limiter** huwa l-punt kruċjali: SendGrid jew Twilio jikkontrollawk ir-rata jew ipoġġuk fuq blacklist jekk taqbeż il-limitu tagħhom. Redis token bucket għal kull provider jillimita l-outbound RPS irrispettivament minn kemm workers qed jaħdmu.
- **DLQ** jaqbad messaġġi velenużi wara N retries b'exponential backoff + jitter, biex indirizz ħażin qatt ma jimblokka l-kampanja.

## Perspettiva tal-intervista

L-intervistatur qed jgħarbel jekk tifhimx **id-decoupling u l-back-pressure**. Tweġiba "eċċellenti" ssemmi l-falliment eżatt: mingħajr idempotency, queue at-least-once flimkien ma' retry ifisser li l-utenti jieħdu tliet codes; mingħajr rate limiter, tagħmel self-DDoS lill-provider u tispiċċa kontrollat sa żero. In-nassa komuni hija li tagħmel il-fan-out b'mod sinkroniku ("just `Promise.all`") — dan iżomm il-connections okkupati, m'għandu ebda retry, u jitlef kollox waqt deploy.

## Trade-offs u fallimenti

- **At-least-once vs exactly-once**: il-queues jagħtu at-least-once bl-irħis; tixtri "effectively once" bid-dedup key ta' Redis, mhux b'broker exactly-once għali.
- **Throughput vs limiti tal-provider**: tista' żżid workers għal dejjem, imma l-kwota tal-provider hija s-saqaf veru — itlob żieda fil-kwota jew agħmel pre-warm qabel il-kampanja.
- **Fallimenti**: Redis down → is-sends jieqfu (fail closed, tinsiex tagħmel skip lid-dedup u tirriskja duplikati). Żomm counter għal kull kampanja biex tkun tista' tkompli, mhux terġa' tibda, wara inċident.

Arkitettura

Komponenti u fluss

Perspettiva tal-intervista

Trade-offs u fallimenti

Mistoqsijiet relatati