कंपनीभर वापरली जाणारी notification service तुम्ही कशी डिझाईन कराल?

Question

IT Interview Practice · Accepted Answer

एक अशी service बनवा जिला प्रत्येक team **notification type + recipient** देऊन कॉल करते, आणि channel, template, युजर preferences आणि priority ठरवणे service वर सोपवा. मुख्य design हालचाल म्हणजे **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}`. कॉल करणारे कधीही channel निवडत नाहीत किंवा मजकूर लिहीत नाहीत — ते 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 काही मिनिटे मागे राहू शकते तरी OTP latency ला स्पर्श होत नाही. हा सर्वात महत्त्वाचा निर्णय आहे.
- **Preference service** प्रत्येक recipient साठी तपासली जाते: opt out केले आहे का? quiet hours? per-channel toggle? frequency cap? preference चे उल्लंघन करणारे marketing इथेच टाकून दिले जाते.
- **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 च्या पुरामुळे OTP उशिरा पोहोचतात. *priority lanes*, *preference enforcement*, आणि *idempotency keys* (जेणेकरून retry केलेली request दोनदा notify करत नाही) नावाने सांगणे हे senior signal आहे. चांगले उत्तर channels जोडते; उत्तम उत्तर OTP आणि marketing कधीही एक queue का शेअर करू नयेत आणि **fallback chain** (Push अपयशी → SMS) कशी चालते हे समजावते.

## तडजोडी आणि अपयश

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

आर्किटेक्चर

घटक आणि प्रवाह

मुलाखतीचा दृष्टिकोन

तडजोडी आणि अपयश

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