Kepiye sampeyan bakal ngrancang layanan notifikasi kanggo saindhenging perusahaan?

Question

IT Interview Practice · Accepted Answer

Gawe siji layanan sing diceluk saben tim nganggo **jinis notifikasi + panampa**, lan ben layanan kuwi sing nemtokake channel, template, preferensi pangguna, lan prioritas. Gerakan rancangan sing paling penting yaiku **priority lanes** — OTP ora bisa ngenteni ing mburi blast marketing kanggo 2 yuta pangguna.

## 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 lan aliran

- **Notify API** nampa request sing wis kaketik jinise: `{type: "otp", user, data}`. Sing nyeluk ora nate milih channel utawa nulis teks — layanan sing nduweni bab kuwi, mula owah-owahan template dikirim sepisan wae.
- **Type → policy**: saben **type** dipetakan menyang sawijining policy. *OTP* prioritase dhuwur, SMS+Push, ora nggatekake opt-out marketing, kadaluwarsa ing 60 detik. *Transactional* (kuitansi, reset sandi) prioritase dhuwur, ngurmati preferensi channel. *Marketing* prioritase endhek, bulk lane, kanthi ketat ngurmati opt-out lan quiet hours.
- **Priority lanes** yaiku topik Kafka sing kapisah kanthi consumer group sing kapisah. Lane dhuwur tetep meh kosong lan mili entek sajrone milidetik; bulk lane bisa numpuk pirang-pirang menit tanpa ndemek latency OTP. Iki minangka keputusan sing paling penting.
- **Preference service** dipriksa saben panampa: opt-out? quiet hours? toggle saben channel? frequency cap? Marketing sing nglanggar preferensi dibuwang ing kene.
- **Template engine** ngrender konten lokal saka template sing diberi versi + variabel, mula teks lan kode kapisah (decoupled).
- **Channel adapters** mbungkus FCM/APNs, SendGrid, Twilio ing sajroning siji antarmuka, saben duwe rate limiter, retry, lan DLQ dhewe (disiplin fan-out sing padha karo sembarang pangirim bulk).

## Sudut pandang wawancara

Pewawancara nyoba niteni apa sampeyan misahake **concern**: akeh kandidat sing mbangun monolit sing ngirim email langsung, banjur nemu yen banjir marketing nunda OTP. Nyebutake *priority lanes*, *penegakan preferensi*, lan *idempotency key* (supaya request sing dicoba maneh ora ngirim notifikasi pindho) minangka sinyal senior. Jawaban apik nambahake channel; jawaban apik banget nerangake kenapa OTP lan marketing ora kena tau nuduhake antrian sing padha lan kepiye **fallback chain** (Push gagal → SMS) nyambut gawe.

## Trade-off lan kegagalan

- **Siji layanan vs saben tim**: pemusatan menehi preferensi, throttling, lan audit sing konsisten, nanging dadi ketergantungan kritis — kudu HA, yen ora, gangguan OTP login bakal ngalang-alangi kabeh perusahaan.
- **Real-time vs biaya**: SMS larang lan alon; luwih becik Push/In-App lan mung balik menyang SMS kanggo jinis sing regane dhuwur.
- **Kegagalan**: gangguan provider micu fallback chain, dudu gagal total. **Dedup key** nyegah pangiriman ulang antrian ngirim OTP kaping pindho. Lacak SLO pangiriman saben jinis — email marketing sing kaselak ora apa-apa, OTP sing kaselak iku insiden.

Arsitektur

Komponen lan aliran

Sudut pandang wawancara

Trade-off lan kegagalan

Pitakon sing gegandhengan