Ta yaya za ka tsara notification service da kamfani gaba ɗaya zai yi amfani da shi?

Question

IT Interview Practice · Accepted Answer

Gina service ɗaya wanda kowace tawaga ke kira da **nau'in notification + mai karɓa**, sannan ka bar service ɗin ya warware channel, template, abubuwan da mai amfani ya fifita, da priority. Babbar dabarar ƙira ita ce **priority lanes** — OTP ba zai iya jira a bayan tallar masu amfani miliyan 2 ba.

## Gine-gine

```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)
```

## Sassa da gudanawa

- **Notify API** yana karɓar typed request: `{type: "otp", user, data}`. Masu kira ba su taɓa zaɓar channel ko rubuta rubutu ba — service ne ke da wannan, don haka canjin template yana tafiya sau ɗaya.
- **Type → policy**: kowane **type** yana taswira zuwa policy. *OTP* mai high-priority ne, SMS+Push, yana yin watsi da opt-out na marketing, kuma yana ƙarewa cikin 60s. *Transactional* (receipt, password reset) mai high ne, yana girmama channel prefs. *Marketing* mai low ne, bulk lane, kuma yana bin opt-out da quiet hours sosai.
- **Priority lanes** su ne Kafka topics daban-daban da consumer groups daban-daban. High lane yana zama kusan babu komai kuma yana zubewa cikin milliseconds; bulk lane na iya cika na tsawon mintuna ba tare da taɓa latency na OTP ba. Wannan shi ne mafi muhimmancin shawara guda ɗaya.
- **Preference service** ana bincika shi ga kowane mai karɓa: ya yi opt out? quiet hours? channel toggle? frequency cap? Marketing da ke karya preference ana zubar da shi a nan.
- **Template engine** yana render localized content daga versioned template + variables, don haka rubutu da code sun rabu.
- **Channel adapters** suna nannaɗe FCM/APNs, SendGrid, Twilio a bayan interface ɗaya, kowanne da rate limiter, retry, da DLQ na kansa (irin fan-out discipline na kowane bulk sender).

## Ra'ayin hira

Masu yin hira suna bincike ko ka raba **concerns**: 'yan takara da yawa suna gina monolith wanda ke aika email kai tsaye, sannan su gano ambaliyar marketing tana jinkirta OTPs. Ambaton *priority lanes*, *preference enforcement*, da *idempotency keys* (don retried request kada ya yi notify sau biyu) shi ne siginar senior. Mai kyau yana ƙara channels; mai kyau sosai yana bayanin dalilin da ya sa OTP da marketing ba za su taɓa raba queue ba da yadda **fallback chain** (Push ya gaza → SMS) ke aiki.

## Sulhu da gazawa

- **Service ɗaya vs kowace tawaga**: tsaka-tsaki yana ba da prefs masu daidaito, throttling, da audit, amma yana zama dogaro mai muhimmanci — dole ya kasance HA, ko kuwa faɗuwar login OTP zai toshe kamfani gaba ɗaya.
- **Real-time vs kuɗi**: SMS mai tsada ne kuma mai jinkiri; fifita Push/In-App kuma ka koma SMS kawai ga types masu daraja.
- **Gazawa**: faɗuwar provider yana kunna fallback chain, ba hard fail ba. **Dedup keys** suna hana redelivery na queue aika OTP sau biyu. Kula da delivery SLOs ga kowane type — jinkirtaccen email na marketing ba matsala ba ce, jinkirtaccen OTP lamari ne.

Gine-gine

Sassa da gudanawa

Ra'ayin hira

Sulhu da gazawa

Tambayoyi masu alaƙa