కంపెనీ అంతటికీ ఉపయోగపడే notification service ను మీరు ఎలా design చేస్తారు?

Question

IT Interview Practice · Accepted Answer

ప్రతి team ఒక **notification type + recipient** తో call చేసే ఒకే service ను నిర్మించండి, మరియు channel, template, user preferences, మరియు priority ను resolve చేయడాన్ని ఆ service కి వదిలేయండి. కీలకమైన design కదలిక **priority lanes** — ఒక OTP 2M-user 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 దాదాపు ఖాళీగా ఉండి millisecond లలో drain అవుతుంది; bulk lane OTP latency ను తాకకుండా నిమిషాల పాటు back up కావచ్చు. ఇది అత్యంత ముఖ్యమైన నిర్ణయం.
- **Preference service** ప్రతి recipient కి check అవుతుంది: opted out? quiet hours? per-channel toggle? frequency cap? preference ను ఉల్లంఘించే marketing ఇక్కడ drop అవుతుంది.
- **Template engine** versioned template + variables నుండి localized content ను render చేస్తుంది, తద్వారా copy మరియు code decouple అవుతాయి.
- **Channel adapters** FCM/APNs, SendGrid, Twilio ను ఒకే interface వెనుక wrap చేస్తాయి, ప్రతి ఒక్కటి దాని స్వంత rate limiter, retry, మరియు DLQ తో (ఏ bulk sender లాంటి fan-out discipline తోనే).

## ఇంటర్వ్యూ దృక్కోణం

మీరు **concerns** ను వేరు చేస్తారా అని ఇంటర్వ్యూయర్‌లు పరిశీలిస్తారు: చాలామంది candidates email ను నేరుగా పంపే monolith ను నిర్మించి, ఆ తర్వాత marketing floods OTPs ను ఆలస్యం చేస్తాయని కనుగొంటారు. *priority lanes*, *preference enforcement*, మరియు *idempotency keys* (తద్వారా retry అయిన request double-notify చేయదు) ను పేర్కొనడం senior signal. మంచిది channels ను జోడిస్తుంది; గొప్పది OTP మరియు marketing ఎప్పుడూ queue ను ఎందుకు పంచుకోకూడదో మరియు **fallback chain** (Push fail → SMS) ఎలా పనిచేస్తుందో వివరిస్తుంది.

## ట్రేడ్-ఆఫ్‌లు మరియు వైఫల్యం

- **One service vs per-team**: centralize చేయడం స్థిరమైన prefs, throttling, మరియు audit ను ఇస్తుంది, కానీ ఒక critical dependency అవుతుంది — అది HA గా ఉండాలి, లేదా login OTP outage మొత్తం కంపెనీని block చేస్తుంది.
- **Real-time vs cost**: SMS ఖరీదైనది మరియు నెమ్మది; Push/In-App ను ఇష్టపడండి మరియు high-value types కోసం మాత్రమే SMS కి fall back అవ్వండి.
- **Failure**: provider outage hard fail కాకుండా fallback chain ను trigger చేస్తుంది. **Dedup keys** queue redelivery OTP ను రెండుసార్లు పంపకుండా నివారిస్తాయి. ఒక్కో type కి delivery SLOs ను track చేయండి — ఆలస్యమైన marketing email పర్వాలేదు, ఆలస్యమైన OTP ఒక incident.

ఆర్కిటెక్చర్

కాంపోనెంట్‌లు మరియు ఫ్లో

ఇంటర్వ్యూ దృక్కోణం

ట్రేడ్-ఆఫ్‌లు మరియు వైఫల్యం

సంబంధిత ప్రశ్నలు