Ta yaya za ka aika lambobin tallace-tallace (promo codes) ga masu amfani miliyan 1 cikin gajeren lokaci?

Question

IT Interview Practice · Accepted Answer

Kada ka taɓa yin loop kan masu amfani miliyan 1 a cikin request handler — **watsa su ta hanyar queue**, ka daidaita gudu zuwa abin da kowane provider zai iya karɓa, ka mai da kowane aikin aikawa **idempotent**, sannan ka tura gazawa zuwa DLQ don sake gwadawa. API call kawai yana shigar da aikin cikin queue; workers ne suke yin I/O mai jinkiri.

## Gine-gine

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

## Sassa da gudanawa

- **Campaign API** yana rubuta campaign ɗin sannan yana shigar da ayyuka cikin queue — ɗaya ga kowane mai amfani ko ga kowace **batch na kusan 500** don rage nauyin queue. Yana dawowa nan take; aikawa miliyan 1 na faruwa a bayan queue.
- **Queue (Kafka / SQS)** shi ne buffer da kuma log ɗin *replay*. Idan workers suka faɗi, saƙonni sun tsaya a wurin; babu wani code da ya ɓace. Yi partition da `user_id` domin tsari (ordering) ga kowane mai amfani ya kasance mai kwanciyar hankali.
- **Worker pool** yana ja ayyuka kuma yana autoscale bisa queue lag. Kowane worker: (1) yana ajiye lambar promo ta musamman, (2) yana bincika **dedup key** `SETNX sent:{campaign}:{user}` a Redis don kada saƙon da aka sake tura ya sake aikawa sau biyu, (3) yana wucewa ta **rate limiter** da aka daidaita zuwa quota na provider, (4) yana kiran Email/SMS/Push.
- **Rate limiter** shi ne ainihin mahimmancin: SendGrid ko Twilio za su rage gudu ko su hana ka sama da iyakarsu. Redis token bucket ga kowane provider yana iyakance outbound RPS ba tare da la'akari da yawan workers da ke gudana ba.
- **DLQ** yana kama poison messages bayan sake gwadawa N tare da exponential backoff + jitter, domin adireshi mara kyau kada ya toshe campaign ɗin.

## Ra'ayin hira

Mai yin hirar yana bincike ko ka fahimci **decoupling da back-pressure**. Amsa "mai kyau sosai" tana ambaton ainihin gazawar: ba tare da idempotency ba, queue na at-least-once tare da retry yana nufin masu amfani su sami lambobi uku; ba tare da rate limiter ba, kai da kanka za ka yi wa provider DDoS kuma a rage ka zuwa sifili. Tarkon da aka saba shi ne yin fan-out ɗin cikin salon synchronous ("`Promise.all` kawai") — wannan yana ɗaure connections, ba shi da retry, kuma yana ɓata komai a lokacin deploy.

## Sulhu da gazawa

- **At-least-once vs exactly-once**: queues suna ba da at-least-once cikin arha; kana samun "kusan sau ɗaya" da Redis dedup key, ba da broker mai tsada na exactly-once ba.
- **Throughput vs iyakar provider**: za ka iya ƙara workers har abada, amma quota na provider shi ne ainihin rufin — nemi ƙara quota ko ka yi pre-warm kafin campaign.
- **Gazawa**: idan Redis ya faɗi → aikawa na tsayawa (fail closed, kada ka tsallake dedup ka haɗari sau biyu). Kula da counter ga kowane campaign domin ka iya ci gaba (resume), ba sake farawa ba, bayan lamari.

Gine-gine

Sassa da gudanawa

Ra'ayin hira

Sulhu da gazawa

Tambayoyi masu alaƙa