छोटो समयावधिमा 10 लाख प्रयोगकर्तालाई प्रोमो कोड कसरी पठाउनुहुन्छ?

Question

IT Interview Practice · Accepted Answer

कहिल्यै पनि request handler भित्र 10 लाख प्रयोगकर्तामाथि loop नचलाउनुहोस् — **queue मार्फत fan out गर्नुहोस्**, प्रत्येक provider ले स्वीकार गर्न सक्ने हदसम्म throttle गर्नुहोस्, प्रत्येक send लाई **idempotent** बनाउनुहोस्, र retry का लागि failure हरूलाई DLQ मा route गर्नुहोस्। API call ले केवल 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** ले campaign लेख्छ र job हरू enqueue गर्छ — प्रति प्रयोगकर्ता एउटा वा queue overhead घटाउन **~500 को batch** प्रति एउटा। यसले तुरुन्तै फर्काउँछ; 10 लाख send queue पछाडि हुन्छन्।
- **Queue (Kafka / SQS)** buffer र *replay* log हो। worker crash भए, message हरू ठाउँमै रहन्छन्; कुनै code हराउँदैन। `user_id` अनुसार partition गर्नुहोस् ताकि प्रति प्रयोगकर्ता ordering स्थिर रहोस्।
- **Worker pool** ले job हरू तान्छ र queue lag अनुसार autoscale हुन्छ। प्रत्येक worker: (1) एउटा अद्वितीय promo code reserve गर्छ, (2) Redis मा `SETNX sent:{campaign}:{user}` भन्ने **dedup key** जाँच्छ ताकि पुनः-डेलिभर भएको message ले कहिल्यै double-send नगरोस्, (3) provider को quota अनुसार आकार दिइएको **rate limiter** मार्फत जान्छ, (4) Email/SMS/Push call गर्छ।
- **Rate limiter** नै मुख्य कुरा हो: SendGrid वा Twilio ले तिनको limit भन्दा माथि तपाईंलाई throttle वा blacklist गर्छ। प्रति provider एउटा Redis token bucket ले कति वटा worker चले पनि outbound RPS मा सीमा राख्छ।
- **DLQ** ले exponential backoff + jitter सहित N retry पछि poison message हरू समात्छ, ताकि एउटा खराब address ले कहिल्यै campaign रोक्न नसकोस्।

## अन्तर्वार्ता दृष्टिकोण

अन्तर्वार्ताकारले तपाईंले **decoupling र back-pressure** बुझ्नुहुन्छ कि भनेर जाँच्दै हुन्छन्। एउटा "उत्कृष्ट" उत्तरले ठ्याक्कै failure नाम दिन्छ: idempotency बिना, at-least-once queue र एउटा retry मिलेर प्रयोगकर्ताले तीन वटा code पाउने हुन्छ; rate limiter बिना, तपाईं आफैँले provider लाई self-DDoS गर्नुहुन्छ र शून्यसम्म throttle हुनुहुन्छ। साधारण जाल भनेको fan-out लाई synchronous रूपमा गर्नु ("just `Promise.all`") हो — यसले connection हरू अल्झाउँछ, कुनै retry हुँदैन, र deploy मा सबै हराउँछ।

## ट्रेड-अफ र failure

- **At-least-once बनाम exactly-once**: queue ले at-least-once सस्तोमा दिन्छ; तपाईंले "effectively once" Redis dedup key ले किन्नुहुन्छ, महँगो exactly-once broker ले होइन।
- **Throughput बनाम provider limit**: तपाईं सधैँ worker थप्न सक्नुहुन्छ, तर provider quota नै वास्तविक सीमा हो — campaign अघि quota bump माग्नुहोस् वा pre-warm गर्नुहोस्।
- **Failure**: Redis down → send हरू अड्किन्छन् (fail closed गर्नुहोस्, dedup नछोड्नुहोस् र double को जोखिम नलिनुहोस्)। प्रति-campaign counter track गर्नुहोस् ताकि incident पछि restart होइन, resume गर्न सकियोस्।

आर्किटेक्चर

कम्पोनेन्ट र प्रवाह

अन्तर्वार्ता दृष्टिकोण

ट्रेड-अफ र failure

सम्बन्धित प्रश्नहरू