Unatumaje promo codes kwa watumiaji milioni 1 katika muda mfupi?

Question

IT Interview Practice · Accepted Answer

Kamwe usizungushe (loop) watumiaji milioni 1 ndani ya request handler — **sambaza kupitia queue (fan out)**, punguza kasi (throttle) hadi kiwango ambacho kila provider anaweza kupokea, fanya kila utumaji uwe **idempotent**, na elekeza makosa kwenye DLQ ili yajaribiwe upya. Wito wa API huweka kazi kwenye foleni tu; workers ndio hufanya I/O ya polepole.

## Usanifu

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

## Vipengele na mtiririko

- **Campaign API** huandika campaign na kuweka jobs kwenye foleni — moja kwa kila mtumiaji au kwa kila **batch ya ~500** ili kupunguza gharama ya queue. Hurudi papo hapo; utumaji wa milioni 1 hufanyika nyuma ya queue.
- **Queue (Kafka / SQS)** ni buffer na log ya *replay*. Ikiwa workers zitaanguka, messages zinabaki mahali pake; hakuna code inayopotea. Gawanya kwa `user_id` (partition) ili mpangilio kwa kila mtumiaji uwe imara.
- **Worker pool** huvuta jobs na hujiongeza (autoscale) kulingana na queue lag. Kila worker: (1) huhifadhi promo code ya kipekee, (2) hukagua **dedup key** `SETNX sent:{campaign}:{user}` katika Redis ili message iliyotumwa tena isituma mara mbili, (3) hupitisha kupitia **rate limiter** yenye ukubwa wa quota ya provider, (4) huita Email/SMS/Push.
- **Rate limiter** ndiyo kiini: SendGrid au Twilio watakupunguzia kasi au kukuweka kwenye blacklist ukizidi kikomo chao. Token bucket ya Redis kwa kila provider huweka kikomo cha outbound RPS bila kujali ni workers wangapi wanaotumika.
- **DLQ** hunasa poison messages baada ya majaribio N pamoja na exponential backoff + jitter, ili anwani mbovu isizuie campaign nzima.

## Mtazamo wa mahojiano

Mhojiwa anachunguza kama unaelewa **decoupling na back-pressure**. Jibu "bora sana" hutaja kosa kamili: bila idempotency, queue ya at-least-once pamoja na retry humaanisha watumiaji kupata codes tatu; bila rate limiter, unajishambulia mwenyewe (self-DDoS) provider na kupunguzwa kasi hadi sifuri. Mtego wa kawaida ni kufanya fan-out kwa synchronous ("tumia `Promise.all` tu") — hilo hufunga connections, halina retry, na hupoteza kila kitu wakati wa deploy.

## Maelewano na hitilafu

- **At-least-once vs exactly-once**: queues hutoa at-least-once kwa bei nafuu; unapata "effectively once" kwa dedup key ya Redis, si kwa broker ghali ya exactly-once.
- **Throughput vs vikomo vya provider**: unaweza kuongeza workers milele, lakini quota ya provider ndiyo dari halisi — omba nyongeza ya quota au fanya pre-warm kabla ya campaign.
- **Hitilafu**: Redis ikizimika → utumaji husimama (fail closed, usiruke dedup na kuhatarisha nakala mbili). Fuatilia counter kwa kila campaign ili uweze kuendelea, si kuanza upya, baada ya tukio.

Usanifu

Vipengele na mtiririko

Mtazamo wa mahojiano

Maelewano na hitilafu

Maswali yanayohusiana