कम्पनी-व्यापी notification service तपाईं कसरी डिजाइन गर्नुहुन्छ?

Question

IT Interview Practice · Accepted Answer

एउटा यस्तो service बनाउनुहोस् जसलाई प्रत्येक team ले **notification type + recipient** दिएर call गर्छ, र service लाई channel, template, प्रयोगकर्ता preference, र priority पत्ता लगाउन दिनुहोस्। मुख्य डिजाइन कदम भनेको **priority lane** हो — एउटा 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}`। Caller हरूले कहिल्यै 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 pref सम्मान गर्छ। *Marketing* low छ, bulk lane, कडा रूपमा opt-out र quiet hours सम्मान गर्छ।
- **Priority lane** हरू छुट्टै consumer group सहितका छुट्टै Kafka topic हुन्। high lane लगभग खाली रहन्छ र milliseconds मै drain हुन्छ; bulk lane OTP latency नछोई मिनेटौं back up हुन सक्छ। यो सबैभन्दा महत्त्वपूर्ण निर्णय हो।
- **Preference service** प्रति recipient जाँचिन्छ: opt out गरेको? quiet hours? प्रति-channel toggle? frequency cap? preference उल्लंघन गर्ने marketing यहीँ drop हुन्छ।
- **Template engine** ले versioned template + variable बाट localized content render गर्छ, त्यसैले copy र code decouple हुन्छन्।
- **Channel adapter** हरूले FCM/APNs, SendGrid, Twilio लाई एउटै interface पछाडि wrap गर्छन्, प्रत्येकसँग आफ्नै rate limiter, retry, र DLQ (कुनै पनि bulk sender जस्तै समान fan-out अनुशासन)।

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

अन्तर्वार्ताकारहरूले तपाईंले **concern** हरू छुट्याउनुहुन्छ कि भनेर जाँच्छन्: धेरै candidate ले एउटा monolith बनाउँछन् जसले सिधै email पठाउँछ, अनि marketing flood ले OTP ढिला गर्छ भनेर पत्ता लगाउँछन्। *priority lane*, *preference enforcement*, र *idempotency key* (ताकि retry गरिएको request ले double-notify नगरोस्) नाम दिनु senior संकेत हो। राम्रोले channel थप्छ; उत्कृष्टले OTP र marketing ले किन कहिल्यै queue साझा गर्नुहुँदैन र **fallback chain** (Push fail → SMS) कसरी काम गर्छ भनेर व्याख्या गर्छ।

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

- **एउटा service बनाम प्रति-team**: केन्द्रीकरणले एकरूप pref, throttling, र audit दिन्छ, तर एउटा critical dependency बन्छ — यो HA हुनैपर्छ, नत्र login OTP outage ले सम्पूर्ण कम्पनी रोक्छ।
- **Real-time बनाम लागत**: SMS महँगो र ढिलो छ; Push/In-App लाई प्राथमिकता दिनुहोस् र उच्च-मूल्यका type का लागि मात्र SMS मा fall back गर्नुहोस्।
- **Failure**: provider outage ले hard fail होइन, fallback chain trigger गर्छ। **Dedup key** ले queue redelivery बाट OTP दुई पटक पठाउनबाट रोक्छ। प्रति-type delivery SLO track गर्नुहोस् — ढिलो marketing email ठीक छ, ढिलो OTP एउटा incident हो।

आर्किटेक्चर

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

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

ट्रेड-अफ र failure

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