తక్కువ సమయంలో 1M యూజర్‌లకు ప్రోమో కోడ్‌లను ఎలా పంపుతారు?

Question

IT Interview Practice · Accepted Answer

ఒక request handler లో 1M యూజర్‌ల మీద ఎప్పుడూ loop వేయకండి — **queue ద్వారా fan out చేయండి**, ప్రతి provider స్వీకరించగలిగే స్థాయికి throttle చేయండి, ప్రతి send ను **idempotent** గా చేయండి, మరియు failures ను retry కోసం DLQ కి route చేయండి. API call కేవలం enqueue మాత్రమే చేస్తుంది; నెమ్మదైన 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 చేస్తుంది — queue overhead ను తగ్గించడానికి ఒక్కో యూజర్‌కి ఒకటి లేదా **~500 బ్యాచ్‌కి** ఒకటి. ఇది వెంటనే return అవుతుంది; 1M sends queue వెనుక జరుగుతాయి.
- **Queue (Kafka / SQS)** buffer మరియు *replay* log. Workers crash అయితే, messages అలాగే ఉంటాయి; ఏ code కోల్పోదు. యూజర్‌కి ordering స్థిరంగా ఉండేలా `user_id` ద్వారా partition చేయండి.
- **Worker pool** jobs ను pull చేసి queue lag పై autoscale అవుతుంది. ప్రతి worker: (1) ఒక ప్రత్యేకమైన promo code ను reserve చేస్తుంది, (2) Redis లో **dedup key** `SETNX sent:{campaign}:{user}` ను check చేస్తుంది తద్వారా redeliver అయిన message ఎప్పుడూ double-send చేయదు, (3) provider quota కు తగినట్లు size చేసిన **rate limiter** గుండా వెళుతుంది, (4) Email/SMS/Push ను call చేస్తుంది.
- **Rate limiter** అనేది కీలకం: SendGrid లేదా Twilio వాటి limit కంటే ఎక్కువైతే మిమ్మల్ని throttle లేదా blacklist చేస్తాయి. ఒక్కో provider కి Redis token bucket ఎన్ని workers నడిచినా outbound RPS ను cap చేస్తుంది.
- **DLQ** exponential backoff + jitter తో N retries తర్వాత poison messages ను పట్టుకుంటుంది, తద్వారా ఒక చెడ్డ address campaign ను ఎప్పుడూ block చేయదు.

## ఇంటర్వ్యూ దృక్కోణం

మీకు **decoupling మరియు back-pressure** అర్థమయ్యిందా అని ఇంటర్వ్యూయర్ పరిశీలిస్తారు. ఒక "గొప్ప" సమాధానం ఖచ్చితమైన failure ను పేర్కొంటుంది: idempotency లేకుండా, at-least-once queue పైన retry కలిపితే యూజర్‌లకు మూడు codes వస్తాయి; rate limiter లేకుండా, మీరు provider ను self-DDoS చేసి zero కి throttle అవుతారు. సర్వసాధారణ ఉచ్చు — fan-out ను synchronous గా చేయడం ("just `Promise.all`") — అది connections ను బంధిస్తుంది, retry ఉండదు, మరియు deploy సమయంలో అంతా కోల్పోతుంది.

## ట్రేడ్-ఆఫ్‌లు మరియు వైఫల్యం

- **At-least-once vs exactly-once**: queues చవకగా at-least-once ను ఇస్తాయి; "effectively once" ను మీరు Redis dedup key తో కొనుగోలు చేస్తారు, ఖరీదైన exactly-once broker తో కాదు.
- **Throughput vs provider limits**: మీరు ఎంతైనా workers ను జోడించవచ్చు, కానీ provider quota నిజమైన పరిమితి — campaign కు ముందు quota bump ను request చేయండి లేదా pre-warm చేయండి.
- **Failure**: Redis down → sends నిలిచిపోతాయి (fail closed, dedup ను skip చేసి doubles ప్రమాదం తీసుకోవద్దు). ఒక్కో campaign కి counter ను track చేయండి తద్వారా incident తర్వాత restart కాకుండా resume చేయవచ్చు.

ఆర్కిటెక్చర్

కాంపోనెంట్‌లు మరియు ఫ్లో

ఇంటర్వ్యూ దృక్కోణం

ట్రేడ్-ఆఫ్‌లు మరియు వైఫల్యం

సంబంధిత ప్రశ్నలు