ਤੁਸੀਂ ਇੱਕ company-wide notification service ਕਿਵੇਂ design ਕਰੋਗੇ?

Question

IT Interview Practice · Accepted Answer

ਇੱਕ ਅਜਿਹੀ service ਬਣਾਓ ਜਿਸਨੂੰ ਹਰ team ਇੱਕ **notification type + recipient** ਨਾਲ call ਕਰੇ, ਅਤੇ service ਨੂੰ channel, template, user preferences, ਅਤੇ priority resolve ਕਰਨ ਦਿਓ। ਮੁੱਖ design move ਹੈ **priority lanes** — ਇੱਕ OTP 20 ਲੱਖ-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 change ਇੱਕੋ ਵਾਰ 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 ਲਈ check ਹੁੰਦੀ ਹੈ: opted out? quiet hours? per-channel toggle? frequency cap? ਜੋ marketing ਕਿਸੇ preference ਦੀ ਉਲੰਘਣਾ ਕਰੇ ਉਹ ਇੱਥੇ 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 discipline)।

## ਇੰਟਰਵਿਊ ਦਾ ਨਜ਼ਰੀਆ

ਇੰਟਰਵਿਊਅਰ ਇਹ ਪਰਖਦੇ ਹਨ ਕਿ ਕੀ ਤੁਸੀਂ **concerns** ਨੂੰ ਵੱਖ ਕਰਦੇ ਹੋ: ਬਹੁਤ ਸਾਰੇ candidates ਇੱਕ monolith ਬਣਾਉਂਦੇ ਹਨ ਜੋ ਸਿੱਧਾ email ਭੇਜਦਾ ਹੈ, ਫਿਰ ਪਤਾ ਲੱਗਦਾ ਹੈ ਕਿ marketing floods OTPs ਨੂੰ ਦੇਰੀ ਕਰਦੇ ਹਨ। *priority lanes*, *preference enforcement*, ਅਤੇ *idempotency keys* (ਤਾਂ ਜੋ retried request double-notify ਨਾ ਕਰੇ) ਦਾ ਨਾਂ ਲੈਣਾ senior signal ਹੈ। ਵਧੀਆ channels ਜੋੜਦਾ ਹੈ; ਸ਼ਾਨਦਾਰ ਇਹ ਸਮਝਾਉਂਦਾ ਹੈ ਕਿ OTP ਅਤੇ marketing ਨੂੰ ਕਦੇ ਇੱਕ queue ਸਾਂਝੀ ਕਿਉਂ ਨਹੀਂ ਕਰਨੀ ਚਾਹੀਦੀ ਅਤੇ ਇੱਕ **fallback chain** (Push fail → SMS) ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ।

## ਟ੍ਰੇਡ-ਆਫ ਅਤੇ ਫੇਲੀਅਰ

- **One service vs per-team**: centralize ਕਰਨ ਨਾਲ consistent prefs, throttling, ਅਤੇ audit ਮਿਲਦੇ ਹਨ, ਪਰ ਇਹ ਇੱਕ critical dependency ਬਣ ਜਾਂਦੀ ਹੈ — ਇਹ HA ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਨਹੀਂ ਤਾਂ ਇੱਕ login OTP outage ਪੂਰੀ company ਨੂੰ block ਕਰ ਦਿੰਦਾ ਹੈ।
- **Real-time vs cost**: SMS ਮਹਿੰਗਾ ਅਤੇ ਹੌਲੀ ਹੈ; Push/In-App ਨੂੰ ਤਰਜੀਹ ਦਿਓ ਅਤੇ SMS ਵੱਲ ਸਿਰਫ਼ high-value types ਲਈ fall back ਕਰੋ।
- **Failure**: ਇੱਕ provider outage fallback chain trigger ਕਰਦਾ ਹੈ, hard fail ਨਹੀਂ। **Dedup keys** ਇੱਕ queue redelivery ਨੂੰ OTP ਦੋ ਵਾਰ ਭੇਜਣ ਤੋਂ ਰੋਕਦੇ ਹਨ। ਹਰ type ਲਈ delivery SLOs track ਕਰੋ — ਇੱਕ ਦੇਰੀ ਵਾਲਾ marketing email ਠੀਕ ਹੈ, ਇੱਕ ਦੇਰੀ ਵਾਲਾ OTP ਇੱਕ incident ਹੈ।

ਆਰਕੀਟੈਕਚਰ

ਕੰਪੋਨੈਂਟ ਅਤੇ ਫਲੋ

ਇੰਟਰਵਿਊ ਦਾ ਨਜ਼ਰੀਆ

ਟ੍ਰੇਡ-ਆਫ ਅਤੇ ਫੇਲੀਅਰ

ਸੰਬੰਧਿਤ ਸਵਾਲ