Ungeundaje huduma ya notification kwa kampuni nzima?

Question

IT Interview Practice · Accepted Answer

Jenga huduma moja ambayo kila timu huiita kwa **notification type + recipient**, na iruhusu huduma kubaini channel, template, mapendeleo ya mtumiaji, na priority. Hatua muhimu ya usanifu ni **priority lanes** — OTP haiwezi kusubiri nyuma ya marketing blast ya watumiaji milioni 2.

## Usanifu

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

## Vipengele na mtiririko

- **Notify API** huchukua request yenye type: `{type: "otp", user, data}`. Waitaji kamwe hawachagui channel wala kuandika maandishi — huduma inamiliki hilo, hivyo mabadiliko ya template hutumwa mara moja.
- **Type → policy**: kila **type** hunganishwa na policy. *OTP* ni priority ya juu, SMS+Push, hupuuza marketing opt-out, humalizika kwa sekunde 60. *Transactional* (risiti, password reset) ni ya juu, huheshimu channel prefs. *Marketing* ni ya chini, bulk lane, huheshimu kabisa opt-out na quiet hours.
- **Priority lanes** ni Kafka topics tofauti zenye consumer groups tofauti. High lane hubaki karibu tupu na hutoka kwa milliseconds; bulk lane inaweza kujaa kwa dakika bila kugusa latency ya OTP. Hili ndilo uamuzi muhimu zaidi.
- **Preference service** hukaguliwa kwa kila recipient: ameopt out? quiet hours? channel toggle? frequency cap? Marketing inayokiuka preference hudondoshwa hapa.
- **Template engine** hutengeneza maudhui yaliyolokalishwa (localized) kutoka template yenye version + variables, hivyo maandishi na code hutenganishwa.
- **Channel adapters** hufunga FCM/APNs, SendGrid, Twilio nyuma ya interface moja, kila mmoja na rate limiter, retry, na DLQ yake (nidhamu ile ile ya fan-out kama sender yeyote ya bulk).

## Mtazamo wa mahojiano

Wahojiwa huchunguza kama unatenganisha **concerns**: watahiniwa wengi hujenga monolith inayotuma email moja kwa moja, kisha hugundua kuwa mafuriko ya marketing hucheleweshsa OTPs. Kutaja *priority lanes*, *utekelezaji wa preference*, na *idempotency keys* (ili request iliyojaribiwa tena isinotify mara mbili) ni ishara ya senior. Nzuri huongeza channels; bora sana hueleza kwa nini OTP na marketing kamwe hazipaswi kushiriki queue moja na jinsi **fallback chain** (Push ikishindwa → SMS) inavyofanya kazi.

## Maelewano na hitilafu

- **Huduma moja vs kwa kila timu**: kuweka kitovu kimoja hutoa prefs, throttling, na audit thabiti, lakini huwa tegemezi muhimu — lazima iwe HA, la sivyo kukatika kwa login OTP kunazuia kampuni nzima.
- **Real-time vs gharama**: SMS ni ghali na ya polepole; pendelea Push/In-App na urudi kwenye SMS kwa types za thamani ya juu tu.
- **Hitilafu**: kukatika kwa provider huchochea fallback chain, si kushindwa kabisa. **Dedup keys** huzuia queue redelivery kutuma OTP mara mbili. Fuatilia delivery SLOs kwa kila type — email ya marketing iliyochelewa ni sawa, OTP iliyochelewa ni tukio.

Usanifu

Vipengele na mtiririko

Mtazamo wa mahojiano

Maelewano na hitilafu

Maswali yanayohusiana