आप एक कंपनी-व्यापी notification service कैसे डिज़ाइन करेंगे?

Question

IT Interview Practice · Accepted Answer

एक ऐसी service बनाएं जिसे हर team एक **notification type + recipient** के साथ कॉल करे, और service को channel, template, यूज़र preferences, और priority हल करने दें। मुख्य डिज़ाइन कदम है **priority lanes** — एक OTP 20 लाख यूज़र्स के marketing blast के पीछे इंतज़ार नहीं कर सकता।

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

```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 नहीं चुनते या copy नहीं लिखते — service उसका मालिक है, इसलिए template बदलाव एक बार ship होता है।
- **Type → policy**: हर **type** एक policy से map होता है। *OTP* high-priority है, SMS+Push, marketing opt-out को नज़रअंदाज़ करता है, 60s में expire होता है। *Transactional* (receipt, password reset) high है, channel prefs का सम्मान करता है। *Marketing* low है, bulk lane, opt-out और quiet hours का सख्ती से पालन करता है।
- **Priority lanes** अलग consumer groups वाले अलग Kafka topics हैं। high lane लगभग खाली रहती है और milliseconds में drain होती है; bulk lane minutes तक भर सकती है बिना OTP latency को छुए। यह सबसे महत्वपूर्ण निर्णय है।
- **Preference service** प्रति recipient चेक होती है: opted out? quiet hours? per-channel toggle? frequency cap? किसी preference का उल्लंघन करने वाला marketing यहीं drop हो जाता है।
- **Template engine** एक versioned template + variables से localized content render करता है, ताकि copy और code decoupled रहें।
- **Channel adapters** FCM/APNs, SendGrid, Twilio को एक interface के पीछे लपेटते हैं, हर एक अपने rate limiter, retry, और DLQ के साथ (किसी भी bulk sender जैसा वही fan-out अनुशासन)।

## इंटरव्यू का नज़रिया

Interviewers परखते हैं कि क्या आप **concerns** अलग करते हैं: कई candidates एक monolith बनाते हैं जो email सीधे भेजता है, फिर पता चलता है कि marketing floods OTPs में देरी करते हैं। *priority lanes*, *preference enforcement*, और *idempotency keys* (ताकि retried request double-notify न करे) नाम लेना senior signal है। अच्छा channels जोड़ता है; बढ़िया समझाता है कि OTP और marketing कभी एक queue साझा क्यों नहीं कर सकते और एक **fallback chain** (Push fail → SMS) कैसे काम करती है।

## ट्रेड-ऑफ़ और failure

- **एक service बनाम per-team**: केंद्रीकरण consistent prefs, throttling, और audit देता है, पर एक critical dependency बन जाता है — इसे HA होना चाहिए, वरना login OTP outage पूरी कंपनी को block कर देता है।
- **Real-time बनाम cost**: SMS महंगा और धीमा है; Push/In-App को प्राथमिकता दें और केवल high-value types के लिए SMS पर fall back करें।
- **Failure**: एक provider outage fallback chain trigger करता है, hard fail नहीं। **Dedup keys** एक queue redelivery को OTP दो बार भेजने से रोकते हैं। प्रति-type delivery SLOs track करें — देर से आया marketing email ठीक है, देर से आया OTP एक incident है।

आर्किटेक्चर

कंपोनेंट्स और फ्लो

इंटरव्यू का नज़रिया

ट्रेड-ऑफ़ और failure

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