நிறுவனம் முழுவதற்குமான notification service-ஐ எப்படி வடிவமைப்பீர்கள்?

Question

IT Interview Practice · Accepted Answer

ஒவ்வொரு குழுவும் ஒரு **notification type + recipient** உடன் அழைக்கும் ஒரே service-ஐ உருவாக்குங்கள், மேலும் channel, template, பயனர் preferences மற்றும் priority-ஐ service தீர்மானிக்கட்டும். முக்கியமான design நகர்வு **priority lanes** — ஒரு OTP ஒரு 2M-பயனர் 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 தேர்ந்தெடுப்பதில்லை அல்லது 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-இல் வடிகிறது; bulk lane OTP latency-ஐத் தொடாமல் நிமிடங்களுக்கு back up ஆகலாம். இது தான் ஒற்றை மிக முக்கியமான முடிவு.
- **Preference service** ஒவ்வொரு recipient-க்கும் சரிபார்க்கப்படுகிறது: opt 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-க்குப் பின்னால் wrap செய்கின்றன, ஒவ்வொன்றுக்கும் அதன் சொந்த rate limiter, retry மற்றும் DLQ (எந்த bulk sender-ஐயும் போன்ற அதே fan-out ஒழுங்கு).

## நேர்காணல் கண்ணோட்டம்

நீங்கள் **concerns**-ஐ பிரிக்கிறீர்களா என்பதை நேர்காணல் செய்பவர்கள் ஆராய்கிறார்கள்: பல வேட்பாளர்கள் நேரடியாக email அனுப்பும் ஒரு monolith உருவாக்குகிறார்கள், பிறகு marketing floods OTP-களைத் தாமதப்படுத்துவதைக் கண்டுபிடிக்கிறார்கள். *priority lanes*, *preference enforcement* மற்றும் *idempotency keys* (retry செய்யப்பட்ட request இரட்டை notify செய்யாதபடி) குறிப்பிடுவது தான் senior சமிக்ஞை. நல்லது channels சேர்க்கிறது; சிறந்தது OTP-ம் marketing-ம் ஒருபோதும் ஒரே queue-ஐப் பகிரக்கூடாது என்பதையும் ஒரு **fallback chain** (Push தோல்வி → SMS) எப்படி வேலை செய்கிறது என்பதையும் விளக்குகிறது.

## சமரசங்களும் தோல்வியும்

- **One service vs per-team**: மையப்படுத்துவது நிலையான prefs, throttling மற்றும் audit தருகிறது, ஆனால் ஒரு critical dependency ஆகிறது — அது HA-ஆக இருக்க வேண்டும், இல்லையெனில் ஒரு login OTP outage முழு நிறுவனத்தையும் தடுக்கிறது.
- **Real-time vs cost**: SMS விலையுயர்ந்தது, மெதுவானது; Push/In-App-ஐ விரும்புங்கள், high-value types-க்கு மட்டுமே SMS-க்கு fall back செய்யுங்கள்.
- **தோல்வி**: ஒரு provider outage fallback chain-ஐத் தூண்டுகிறது, hard fail அல்ல. **Dedup keys** ஒரு queue redelivery ஒரு OTP-ஐ இருமுறை அனுப்புவதைத் தடுக்கிறது. ஒவ்வொரு type-க்கும் delivery SLO-களைக் கண்காணியுங்கள் — தாமதமான marketing email பரவாயில்லை, தாமதமான OTP ஒரு சம்பவம்.

கட்டமைப்பு

கூறுகளும் ஓட்டமும்

நேர்காணல் கண்ணோட்டம்

சமரசங்களும் தோல்வியும்

தொடர்புடைய கேள்விகள்