Si i dërgoni kode promocionale te 1M përdorues brenda një dritareje të shkurtër kohore?

Question

IT Interview Practice · Accepted Answer

Kurrë mos bëni loop mbi 1M përdorues brenda një request handler — **shpërndani përmes një queue (fan out)**, kufizoni ritmin (throttle) sipas asaj që mund të pranojë secili provider, bëjeni çdo dërgim **idempotent**, dhe drejtoni dështimet drejt një DLQ për riprovim. Thirrja e API-t vetëm i vendos në queue; workers bëjnë I/O-në e ngadaltë.

## Arkitektura

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

## Komponentët dhe rrjedha

- **Campaign API** shkruan fushatën dhe vendos jobs në queue — një për çdo përdorues ose një për **batch prej ~500** për të ulur overhead-in e queue. Kthehet menjëherë; 1M dërgimet ndodhin prapa queue.
- **Queue (Kafka / SQS)** është buffer-i dhe log-u i *replay*. Nëse workers rrëzohen, mesazhet mbeten në vend; asnjë punë nuk humbet. Partition sipas `user_id` që renditja për çdo përdorues të jetë e qëndrueshme.
- **Worker pool** tërheq jobs dhe autoscale sipas queue lag. Çdo worker: (1) rezervon një kod promocional unik, (2) kontrollon një **dedup key** `SETNX sent:{campaign}:{user}` në Redis që një mesazh i ridërguar të mos dërgojë kurrë dy herë, (3) kalon përmes një **rate limiter** të dimensionuar sipas kuotës së provider-it, (4) thërret Email/SMS/Push.
- **Rate limiter** është thelbi: SendGrid ose Twilio do t'ju bëjnë throttle ose do t'ju vendosin në blacklist mbi limitin e tyre. Një token bucket Redis për çdo provider kufizon RPS-në dalëse pavarësisht sa workers po ekzekutohen.
- **DLQ** kap mesazhet poison pas N riprovimeve me exponential backoff + jitter, kështu që një adresë e keqe nuk e bllokon kurrë fushatën.

## Këndvështrimi i intervistës

Intervistuesi po heton nëse i kuptoni **decoupling dhe back-pressure**. Një përgjigje "e shkëlqyer" emërton dështimin e saktë: pa idempotency, një queue at-least-once plus një retry do të thotë përdorues që marrin tre kode; pa një rate limiter, i bëni self-DDoS provider-it dhe ju bëjnë throttle deri në zero. Kurthi i zakonshëm është ta bësh fan-out-in në mënyrë sinkrone ("thjesht `Promise.all`") — kjo zë lidhjet, nuk ka retry, dhe humbet gjithçka gjatë një deploy.

## Kompromiset dhe dështimi

- **At-least-once vs exactly-once**: queue-t japin at-least-once lirë; ju blini "effectively once" me dedup key-in e Redis, jo me një broker të shtrenjtë exactly-once.
- **Throughput vs limitet e provider-it**: mund të shtoni workers pafundësisht, por kuota e provider-it është tavani i vërtetë — kërkoni një rritje kuote ose pre-warm para fushatës.
- **Dështimi**: Redis poshtë → dërgimet ndalen (fail closed, mos e kapërceni dedup-in dhe mos rrezikoni dublikata). Mbani një counter për çdo fushatë që të mund të rifilloni (resume), jo të restartoni, pas një incidenti.

Arkitektura

Komponentët dhe rrjedha

Këndvështrimi i intervistës

Kompromiset dhe dështimi

Pyetje të ngjashme