آپ ایک مختصر وقفے میں 10 لاکھ صارفین کو promo codes کیسے بھیجتے ہیں؟

Question

IT Interview Practice · Accepted Answer

کبھی بھی request handler کے اندر 10 لاکھ صارفین پر loop نہ چلائیں — بلکہ **queue کے ذریعے fan out کریں**، ہر provider جتنا قبول کر سکے اُتنا throttle کریں، ہر send کو **idempotent** بنائیں، اور ناکامیوں کو 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 کرتی ہے — ہر صارف کے لیے ایک، یا **تقریباً 500 کے batch** کے لیے ایک تاکہ queue کا overhead کم ہو۔ یہ فوراً واپس آ جاتی ہے؛ 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) ایک منفرد promo code reserve کرتا ہے، (2) Redis میں ایک **dedup key** `SETNX sent:{campaign}:{user}` چیک کرتا ہے تاکہ دوبارہ پہنچایا گیا message کبھی double-send نہ کرے، (3) provider کے quota کے مطابق ایک **rate limiter** سے گزرتا ہے، (4) Email/SMS/Push کال کرتا ہے۔
- **Rate limiter** اصل کلید ہے: SendGrid یا Twilio اپنی حد سے اوپر آپ کو throttle یا blacklist کر دیں گے۔ ہر provider کے لیے ایک Redis token bucket outbound RPS کو محدود رکھتا ہے، چاہے کتنے ہی workers چل رہے ہوں۔
- **DLQ** N retries کے بعد exponential backoff + jitter کے ساتھ poison messages کو پکڑتا ہے، تاکہ ایک خراب address پوری campaign کو نہ روکے۔

## انٹرویو کا نقطۂ نظر

انٹرویو لینے والا جانچتا ہے کہ آپ **decoupling اور back-pressure** کو سمجھتے ہیں یا نہیں۔ ایک "عمدہ" جواب اصل ناکامی کا نام لیتا ہے: idempotency کے بغیر، at-least-once queue کے ساتھ ایک retry کا مطلب ہے کہ صارفین کو تین codes مل جائیں؛ rate limiter کے بغیر آپ خود provider پر self-DDoS کرتے ہیں اور صفر تک throttle ہو جاتے ہیں۔ عام جال یہ ہے کہ fan-out کو synchronously کیا جائے ("بس `Promise.all`") — یہ connections کو باندھ دیتا ہے، اس میں retry نہیں ہوتا، اور deploy پر سب کچھ ضائع ہو جاتا ہے۔

## توازن اور ناکامی

- **At-least-once بمقابلہ exactly-once**: queues سستے میں at-least-once دیتی ہیں؛ آپ "مؤثر طور پر ایک بار" کو Redis dedup key سے خریدتے ہیں، نہ کہ کسی مہنگے exactly-once broker سے۔
- **Throughput بمقابلہ provider حدود**: آپ workers ہمیشہ کے لیے بڑھا سکتے ہیں، مگر provider quota ہی اصل چھت ہے — campaign سے پہلے quota میں اضافے کی درخواست کریں یا pre-warm کریں۔
- **ناکامی**: Redis نیچے → sends رک جاتے ہیں (fail closed کریں، dedup نہ چھوڑیں ورنہ doubles کا خطرہ)۔ ہر campaign کا ایک counter رکھیں تاکہ کسی واقعے کے بعد آپ دوبارہ شروع نہیں بلکہ resume کر سکیں۔

فن تعمیر

اجزاء اور بہاؤ

انٹرویو کا نقطۂ نظر

توازن اور ناکامی

متعلقہ سوالات