آپ ایک کمپنی بھر کی notification service کیسے ڈیزائن کریں گے؟

Question

IT Interview Practice · Accepted Answer

ایک ایسی service بنائیں جسے ہر team ایک **notification type + recipient** کے ساتھ کال کرے، اور service کو channel، template، صارف کی ترجیحات اور priority حل کرنے دیں۔ کلیدی ڈیزائن اقدام **priority lanes** ہے — ایک OTP 20 لاکھ صارفین کے marketing دھماکے کے پیچھے انتظار نہیں کر سکتا۔

## فن تعمیر

```text
Services ─▶ Notify API ─▶ [validate + enrich] ─▶ Kafka topics
                                                 ├─ otp/txn  (high lane)
                                                 └─ marketing (bulk lane)
                                                      │
                            ┌──── Dispatcher (per lane) ────┐
                            │ prefs check ─▶ template render │
                            └────┬──────┬──────┬────────────┘
                              Push   Email   SMS   In-App
                                 (provider adapters + rate limit)
```

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

- **Notify API** ایک typed request لیتی ہے: `{type: "otp", user, data}`۔ callers کبھی channel نہیں چنتے اور نہ ہی متن لکھتے ہیں — service اس کی مالک ہے، لہٰذا template میں تبدیلی ایک بار ship ہوتی ہے۔
- **Type → policy**: ہر **type** ایک policy سے map ہوتا ہے۔ *OTP* اعلیٰ priority ہے، SMS+Push، marketing opt-out کو نظرانداز کرتا ہے، 60s میں expire ہوتا ہے۔ *Transactional* (receipt، password reset) اعلیٰ ہے، channel prefs کا احترام کرتا ہے۔ *Marketing* کم ہے، bulk lane، سختی سے opt-out اور quiet hours کا احترام کرتا ہے۔
- **Priority lanes** الگ Kafka topics ہیں جن کے الگ consumer groups ہیں۔ high lane تقریباً خالی رہتی ہے اور milliseconds میں drain ہوتی ہے؛ bulk lane منٹوں تک back up ہو سکتی ہے بغیر OTP latency کو چھوئے۔ یہ سب سے اہم فیصلہ ہے۔
- **Preference service** ہر recipient کے لیے چیک کی جاتی ہے: opted out؟ quiet hours؟ per-channel toggle؟ frequency cap؟ جو marketing کسی ترجیح کی خلاف ورزی کرے یہاں drop ہو جاتی ہے۔
- **Template engine** ایک versioned template + variables سے localized content render کرتا ہے، تاکہ متن اور code decoupled رہیں۔
- **Channel adapters** FCM/APNs، SendGrid، Twilio کو ایک interface کے پیچھے wrap کرتے ہیں، ہر ایک کا اپنا rate limiter، retry اور DLQ ہوتا ہے (کسی بھی bulk sender جیسا وہی fan-out نظم)۔

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

انٹرویو لینے والے جانچتے ہیں کہ آپ **concerns** کو الگ کرتے ہیں یا نہیں: بہت سے امیدوار ایک monolith بناتے ہیں جو براہِ راست email بھیجتا ہے، پھر پتا چلتا ہے کہ marketing کے سیلاب OTPs میں تاخیر کر دیتے ہیں۔ *priority lanes*، *preference enforcement*، اور *idempotency keys* (تاکہ دوبارہ بھیجی گئی request double-notify نہ کرے) کا نام لینا senior signal ہے۔ اچھا channels شامل کرتا ہے؛ عمدہ یہ بتاتا ہے کہ OTP اور marketing کو کبھی queue کیوں شیئر نہیں کرنی چاہیے اور ایک **fallback chain** (Push ناکام → SMS) کیسے کام کرتی ہے۔

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

- **ایک service بمقابلہ per-team**: مرکزیت مستقل prefs، throttling اور audit دیتی ہے، مگر یہ ایک critical dependency بن جاتی ہے — اسے HA ہونا چاہیے، ورنہ ایک login OTP outage پوری کمپنی کو روک دیتا ہے۔
- **Real-time بمقابلہ لاگت**: SMS مہنگا اور سست ہے؛ Push/In-App کو ترجیح دیں اور صرف اعلیٰ قدر والے types کے لیے SMS پر fall back کریں۔
- **ناکامی**: ایک provider outage fallback chain کو trigger کرتا ہے، نہ کہ سخت fail۔ **Dedup keys** ایک queue redelivery کو OTP دو بار بھیجنے سے روکتے ہیں۔ per-type delivery SLOs کو track کریں — تاخیر شدہ marketing email ٹھیک ہے، تاخیر شدہ OTP ایک incident ہے۔

فن تعمیر

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

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

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

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