Kako bi zasnovali storitev za obveščanje (notification service) na ravni celega podjetja?

Question

IT Interview Practice · Accepted Answer

Zgradite eno storitev, ki jo vsaka ekipa kliče s **tipom obvestila + prejemnikom**, storitev pa naj razreši kanal, predlogo (template), uporabniške preference in prioriteto. Ključna zasnovna poteza so **prioritetni pasovi (priority lanes)** — OTP ne sme čakati za marketinškim izbruhom na 2M uporabnikov.

## Arhitektura

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

## Komponente in potek

- **Notify API** sprejme tipizirano zahtevo: `{type: "otp", user, data}`. Klicatelji nikoli ne izberejo kanala ali pišejo besedila — to je v lasti storitve, tako da se sprememba predloge izda enkrat.
- **Tip → politika (policy)**: vsak **tip** je preslikan v politiko. *OTP* je visoke prioritete, SMS+Push, ignorira marketinško odjavo (opt-out), poteče v 60s. *Transakcijski* (potrdilo, ponastavitev gesla) je visok, spoštuje preference kanala. *Marketing* je nizek, bulk pas, strogo spoštuje opt-out in tihe ure (quiet hours).
- **Prioritetni pasovi** so ločeni Kafka topici z ločenimi consumer skupinami. Visoki pas ostaja skoraj prazen in se izprazni v milisekundah; bulk pas se lahko zamaši za minute, ne da bi vplival na latenco OTP. To je najpomembnejša odločitev.
- **Storitev preferenc (preference service)** se preveri za vsakega prejemnika: odjavljen? tihe ure? preklop na kanal? frekvenčna omejitev (frequency cap)? Marketing, ki krši preferenco, se tu zavrže.
- **Predložni pogon (template engine)** izriše lokalizirano vsebino iz verzionirane predloge + spremenljivk, tako da sta besedilo in koda razklopljena (decoupled).
- **Kanalni adapterji** ovijejo FCM/APNs, SendGrid, Twilio za enim vmesnikom, vsak s svojim rate limiterjem, ponovnim poskusom in DLQ (enaka fan-out disciplina kot pri katerem koli bulk pošiljatelju).

## Pogled s stališča razgovora

Izpraševalci preverjajo, ali ločujete **skrbi (concerns)**: mnogi kandidati zgradijo monolit, ki pošilja e-pošto neposredno, nato pa odkrijejo, da marketinške poplave zakasnijo OTP-je. Poimenovanje *prioritetnih pasov*, *uveljavljanja preferenc* in *idempotenčnih ključev* (da ponovljena zahteva ne obvesti dvakrat) je signal seniornosti. Dobro doda kanale; odlično pojasni, zakaj OTP in marketing nikoli ne smeta deliti vrste in kako deluje **veriga rezervnih možnosti (fallback chain)** (Push odpove → SMS).

## Kompromisi in odpovedi

- **Ena storitev proti storitvi na ekipo**: centralizacija daje konsistentne preference, throttling in revizijo (audit), a postane kritična odvisnost — mora biti HA, sicer izpad OTP za prijavo blokira celotno podjetje.
- **Realni čas proti stroškom**: SMS je drag in počasen; raje uporabite Push/In-App in preklopite na SMS le za tipe visoke vrednosti.
- **Odpoved**: izpad ponudnika sproži verigo rezervnih možnosti, ne trde napake. **Dedup ključi** preprečijo, da bi ponovna dostava iz vrste poslala OTP dvakrat. Sledite SLO dostave na tip — zakasnjena marketinška e-pošta je v redu, zakasnjen OTP je incident.

Arhitektura

Komponente in potek

Pogled s stališča razgovora

Kompromisi in odpovedi

Povezana vprašanja