कमी वेळेत 10 लाख युजरना प्रोमो कोड कसे पाठवाल?

Question

IT Interview Practice · Accepted Answer

रिक्वेस्ट हँडलरमध्ये 10 लाख युजरवर कधीही loop करू नका — **queue मधून fan out करा**, प्रत्येक provider जेवढे स्वीकारू शकतो तेवढ्यापुरते throttle करा, प्रत्येक send **idempotent** बनवा, आणि retry साठी अपयशी संदेश DLQ कडे route करा. API कॉल फक्त enqueue करते; slow I/O worker करतात.

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

```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** कॅम्पेन लिहिते आणि jobs enqueue करते — प्रत्येक युजरमागे एक किंवा **~500 च्या batch** मागे एक, जेणेकरून queue चा overhead कमी होतो. ती तत्काळ return होते; 10 लाख send queue च्या मागे होतात.
- **Queue (Kafka / SQS)** हा buffer आणि *replay* log आहे. Worker crash झाले, तरी संदेश तिथेच राहतात; कोणताही code हरवत नाही. `user_id` नुसार partition करा जेणेकरून प्रत्येक युजरसाठी ordering स्थिर राहील.
- **Worker pool** jobs घेतो आणि queue lag नुसार autoscale होतो. प्रत्येक worker: (1) एक unique प्रोमो कोड reserve करतो, (2) Redis मध्ये **dedup key** `SETNX sent:{campaign}:{user}` तपासतो जेणेकरून पुन्हा deliver झालेला संदेश कधीही double-send होणार नाही, (3) provider च्या quota नुसार आकारलेल्या **rate limiter** मधून जातो, (4) Email/SMS/Push कॉल करतो.
- **Rate limiter** हा कळीचा मुद्दा आहे: SendGrid किंवा Twilio त्यांच्या मर्यादेपलीकडे गेल्यास तुम्हाला throttle किंवा blacklist करतील. प्रत्येक provider साठी एक Redis token bucket outbound RPS कॅप करते, कितीही worker चालत असोत.
- **DLQ** exponential backoff + jitter सह N retry नंतर poison messages पकडते, जेणेकरून एखादा चुकीचा address कॅम्पेन थांबवत नाही.

## मुलाखतीचा दृष्टिकोन

मुलाखत घेणारा तुम्हाला **decoupling आणि back-pressure** समजते का हे तपासतो. "उत्तम" उत्तर नेमके अपयश नावाने सांगते: idempotency शिवाय, at-least-once queue अधिक retry म्हणजे युजरना तीन कोड मिळणे; rate limiter शिवाय, तुम्ही स्वतःच provider ला self-DDoS करता आणि शून्यापर्यंत throttle होता. सामान्य सापळा म्हणजे fan-out synchronously करणे ("फक्त `Promise.all`") — त्यामुळे connections अडकतात, retry नसते, आणि deploy वर सर्व हरवते.

## तडजोडी आणि अपयश

- **At-least-once vs exactly-once**: queue स्वस्तात at-least-once देतात; "effectively once" तुम्ही Redis dedup key ने विकत घेता, महागड्या exactly-once broker ने नव्हे.
- **Throughput vs provider limits**: तुम्ही worker अखंड जोडू शकता, पण provider quota हीच खरी कमाल मर्यादा आहे — कॅम्पेनआधी quota वाढवण्याची विनंती करा किंवा pre-warm करा.
- **अपयश**: Redis down → sends अडकतात (fail closed करा, dedup वगळून double चा धोका घेऊ नका). प्रत्येक कॅम्पेनसाठी एक counter ठेवा जेणेकरून घटनेनंतर तुम्ही restart नव्हे तर resume करू शकता.

आर्किटेक्चर

घटक आणि प्रवाह

मुलाखतीचा दृष्टिकोन

तडजोडी आणि अपयश

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