Bagaimana anda mereka bentuk perkhidmatan notifikasi merentas seluruh syarikat?

Question

IT Interview Practice · Accepted Answer

Bina satu perkhidmatan yang dipanggil oleh setiap pasukan dengan **jenis notifikasi + penerima**, dan biarkan perkhidmatan itu menentukan channel, template, keutamaan pengguna, dan priority. Gerak reka bentuk utama ialah **priority lanes** — sebuah OTP tidak boleh menunggu di belakang blast pemasaran 2J pengguna.

## Seni bina

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

## Komponen dan aliran

- **Notify API** menerima permintaan bertaip: `{type: "otp", user, data}`. Pemanggil tidak pernah memilih channel atau menulis copy — perkhidmatan itu yang menguruskannya, jadi perubahan template dihantar sekali sahaja.
- **Type → policy**: setiap **type** dipetakan kepada satu policy. *OTP* adalah high-priority, SMS+Push, mengabaikan marketing opt-out, tamat tempoh dalam 60s. *Transactional* (resit, set semula kata laluan) adalah high, menghormati keutamaan channel. *Marketing* adalah low, bulk lane, menghormati opt-out dan quiet hours dengan ketat.
- **Priority lanes** ialah Kafka topics berasingan dengan consumer group berasingan. High lane kekal hampir kosong dan dikosongkan dalam milisaat; bulk lane boleh tersekat selama beberapa minit tanpa menyentuh latency OTP. Ini ialah keputusan yang paling penting sekali.
- **Preference service** disemak bagi setiap penerima: opted out? quiet hours? togol per-channel? had kekerapan? Marketing yang melanggar keutamaan digugurkan di sini.
- **Template engine** merender kandungan setempat (localized) daripada template berversi + pemboleh ubah, jadi copy dan kod ter-decouple.
- **Channel adapters** membalut FCM/APNs, SendGrid, Twilio di sebalik satu antara muka, masing-masing dengan rate limiter, retry, dan DLQ tersendiri (disiplin fan-out yang sama seperti mana-mana penghantar pukal).

## Perspektif temu duga

Penemu duga menyiasat sama ada anda memisahkan **concerns**: ramai calon membina monolit yang menghantar email secara terus, kemudian mendapati banjir marketing melengahkan OTP. Menyebut *priority lanes*, *penguatkuasaan keutamaan*, dan *idempotency keys* (supaya permintaan yang di-retry tidak menotifikasi dua kali) ialah isyarat senior. Baik menambah channel; hebat menerangkan mengapa OTP dan marketing tidak boleh berkongsi queue dan bagaimana **fallback chain** (Push gagal → SMS) berfungsi.

## Pertukaran dan kegagalan

- **Satu perkhidmatan vs setiap pasukan**: pemusatan memberi keutamaan, throttling, dan audit yang konsisten, tetapi menjadi kebergantungan kritikal — ia mesti HA, atau gangguan OTP log masuk menyekat seluruh syarikat.
- **Masa nyata vs kos**: SMS mahal dan perlahan; utamakan Push/In-App dan fallback ke SMS hanya untuk jenis bernilai tinggi.
- **Kegagalan**: gangguan provider mencetuskan fallback chain, bukan kegagalan keras. **Dedup keys** menghalang penghantaran semula queue daripada menghantar OTP dua kali. Jejak SLO penghantaran setiap jenis — email marketing yang lewat tidak mengapa, OTP yang lewat ialah satu insiden.

Seni bina

Komponen dan aliran

Perspektif temu duga

Pertukaran dan kegagalan

Soalan berkaitan