Bagaimana Anda merancang layanan notifikasi berskala perusahaan (company-wide)?

Question

IT Interview Practice · Accepted Answer

Bangun satu layanan yang dipanggil setiap tim dengan **tipe notifikasi + penerima**, dan biarkan layanan itu menyelesaikan channel, template, preferensi pengguna, dan prioritas. Langkah desain kuncinya adalah **priority lanes** — sebuah OTP tidak boleh menunggu di belakang blast marketing untuk 2 juta pengguna.

## Arsitektur

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

- **Notify API** menerima request bertipe: `{type: "otp", user, data}`. Pemanggil tidak pernah memilih channel atau menulis teks — layanan yang memilikinya, sehingga perubahan template dikirim sekali saja.
- **Type → policy**: setiap **type** dipetakan ke sebuah policy. *OTP* berprioritas tinggi, SMS+Push, mengabaikan opt-out marketing, kedaluwarsa dalam 60 detik. *Transactional* (struk, reset password) berprioritas tinggi, menghormati preferensi channel. *Marketing* berprioritas rendah, bulk lane, dengan ketat menghormati opt-out dan quiet hours.
- **Priority lanes** adalah Kafka topic terpisah dengan consumer group terpisah. High lane tetap nyaris kosong dan terkuras dalam milidetik; bulk lane bisa menumpuk selama beberapa menit tanpa menyentuh latensi OTP. Ini adalah keputusan tunggal yang paling penting.
- **Preference service** diperiksa per penerima: sudah opt-out? quiet hours? toggle per-channel? frequency cap? Marketing yang melanggar preferensi dibuang di sini.
- **Template engine** merender konten terlokalisasi dari template berversi + variabel, sehingga teks dan kode ter-decouple.
- **Channel adapters** membungkus FCM/APNs, SendGrid, Twilio di balik satu antarmuka, masing-masing dengan rate limiter, retry, dan DLQ sendiri (disiplin fan-out yang sama seperti pengirim bulk mana pun).

## Perspektif wawancara

Pewawancara menguji apakah Anda memisahkan **concern**: banyak kandidat membangun monolit yang mengirim email langsung, lalu menemukan banjir marketing menunda OTP. Menyebut *priority lanes*, *penegakan preferensi*, dan *idempotency keys* (agar request yang di-retry tidak menotifikasi ganda) adalah sinyal senior. Baik menambahkan channel; hebat menjelaskan mengapa OTP dan marketing tidak boleh berbagi queue serta bagaimana sebuah **fallback chain** (Push gagal → SMS) bekerja.

## Trade-off dan kegagalan

- **Satu layanan vs per-tim**: sentralisasi memberi preferensi, throttling, dan audit yang konsisten, tetapi menjadi dependensi kritis — layanan itu harus HA, atau padamnya OTP login memblokir seluruh perusahaan.
- **Real-time vs biaya**: SMS mahal dan lambat; utamakan Push/In-App dan fallback ke SMS hanya untuk tipe bernilai tinggi.
- **Kegagalan**: padamnya provider memicu fallback chain, bukan hard fail. **Dedup keys** mencegah redelivery queue mengirim OTP dua kali. Lacak SLO pengiriman per-tipe — email marketing yang tertunda tidak masalah, OTP yang tertunda adalah insiden.

Arsitektur

Komponen dan alur

Perspektif wawancara

Trade-off dan kegagalan

Pertanyaan terkait