आप कम समय की विंडो में 10 लाख यूज़र्स को प्रोमो कोड कैसे भेजते हैं?

Question

IT Interview Practice · Accepted Answer

किसी request handler में 10 लाख यूज़र्स पर कभी loop न चलाएं — **एक queue के ज़रिए fan out करें**, हर provider जितना स्वीकार कर सके उतना ही throttle करें, हर send को **idempotent** बनाएं, और failures को retry के लिए DLQ पर route करें। API call सिर्फ enqueue करती है; slow I/O का काम workers करते हैं।

## आर्किटेक्चर

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

## कंपोनेंट्स और फ्लो

- **Campaign API** campaign लिखती है और jobs enqueue करती है — प्रति यूज़र एक, या **~500 का batch** प्रति job ताकि queue overhead घटे। यह तुरंत return कर देती है; 10 लाख sends queue के पीछे होते हैं।
- **Queue (Kafka / SQS)** buffer और *replay* log है। अगर workers crash हो जाएं तो messages वहीं रहते हैं; कोई code खोता नहीं। `user_id` से partition करें ताकि प्रति यूज़र ordering स्थिर रहे।
- **Worker pool** jobs खींचता है और queue lag पर autoscale करता है। हर worker: (1) एक unique promo code reserve करता है, (2) Redis में एक **dedup key** `SETNX sent:{campaign}:{user}` चेक करता है ताकि redelivered message कभी double-send न हो, (3) provider के quota के हिसाब से सेट किए गए **rate limiter** से गुज़रता है, (4) Email/SMS/Push कॉल करता है।
- **Rate limiter** मूल बात है: SendGrid या Twilio अपनी limit से ऊपर आपको throttle या blacklist कर देंगे। प्रति provider एक Redis token bucket outbound RPS को cap करता है, चाहे कितने भी workers चल रहे हों।
- **DLQ** N retries (exponential backoff + jitter के साथ) के बाद poison messages को पकड़ता है, ताकि एक गलत address पूरी campaign को block न करे।

## इंटरव्यू का नज़रिया

Interviewer यह परख रहा है कि क्या आप **decoupling और back-pressure** समझते हैं। एक "बढ़िया" जवाब सटीक failure बताता है: idempotency के बिना, at-least-once queue plus retry का मतलब है यूज़र्स को तीन कोड मिलना; rate limiter के बिना, आप provider पर self-DDoS कर देते हैं और throttle होकर शून्य पर आ जाते हैं। आम जाल है fan-out को synchronously करना ("बस `Promise.all`") — यह connections को बांध देता है, retry नहीं होता, और एक deploy पर सब कुछ खो देता है।

## ट्रेड-ऑफ़ और failure

- **At-least-once बनाम exactly-once**: queues सस्ते में at-least-once देती हैं; "प्रभावी रूप से एक बार" आप Redis dedup key से खरीदते हैं, महंगे exactly-once broker से नहीं।
- **Throughput बनाम provider limits**: आप हमेशा workers जोड़ सकते हैं, पर असली छत provider quota है — campaign से पहले quota bump मांगें या pre-warm करें।
- **Failure**: Redis down → sends अटक जाते हैं (fail closed रहें, dedup skip करके doubles का जोखिम न लें)। प्रति-campaign एक counter track करें ताकि किसी incident के बाद आप restart नहीं, resume कर सकें।

आर्किटेक्चर

कंपोनेंट्स और फ्लो

इंटरव्यू का नज़रिया

ट्रेड-ऑफ़ और failure

संबंधित प्रश्न