તમે કંપની-વ્યાપી notification service કેવી રીતે ડિઝાઇન કરશો?

Question

IT Interview Practice · Accepted Answer

એક service બનાવો જેને દરેક team **notification type + recipient** સાથે કૉલ કરે, અને service ને channel, template, user preferences, અને priority resolve કરવા દો. મુખ્ય ડિઝાઇન ચાલ એ **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)
```

## કમ્પોનન્ટ્સ અને flow

- **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 ને ignore કરે છે, 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 લગભગ ખાલી રહે છે અને મિલિસેકન્ડ્સ માં drain થાય છે; bulk lane OTP latency ને સ્પર્શ કર્યા વગર મિનિટો સુધી back up થઈ શકે છે. આ સૌથી મહત્વનો નિર્ણય છે.
- **Preference service** પ્રતિ recipient તપાસાય છે: opted out? quiet hours? per-channel toggle? frequency cap? જે marketing preference નું ઉલ્લંઘન કરે તે અહીં 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 એક monolith બનાવે છે જે સીધો email મોકલે છે, પછી શોધે છે કે marketing floods OTPs ને વિલંબિત કરે છે. *priority lanes*, *preference enforcement*, અને *idempotency keys* (જેથી retried request બે વાર notify ન કરે) નું નામ આપવું એ senior signal છે. Good channels ઉમેરે છે; great સમજાવે છે કે OTP અને marketing ક્યારેય એક queue share ન કરે, અને એક **fallback chain** (Push fails → SMS) કેવી રીતે કામ કરે છે.

## Trade-offs અને failure

- **એક service vs per-team**: કેન્દ્રીકરણ consistent 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 fallback chain ને trigger કરે છે, hard fail નહીં. **Dedup keys** queue redelivery ને OTP બે વાર મોકલવાથી અટકાવે છે. પ્રતિ-type delivery SLOs track કરો — વિલંબિત marketing email ઠીક છે, વિલંબિત OTP એ incident છે.

આર્કિટેક્ચર

કમ્પોનન્ટ્સ અને flow

ઇન્ટરવ્યૂ દૃષ્ટિકોણ

Trade-offs અને failure

સંબંધિત પ્રશ્નો