Kako biste dizajnirali servis za obavijesti na razini cijele tvrtke?

Question

IT Interview Practice · Accepted Answer

Izgradite jedan servis koji svaki tim poziva s **tipom obavijesti + primateljem**, a servis neka razriješi kanal, predložak, korisničke preferencije i prioritet. Ključni dizajnerski potez su **prioritetne trake (priority lanes)** — OTP ne smije čekati iza marketinškog slanja za 2 milijuna korisnika.

## 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 i tok

- **Notify API** prima tipizirani zahtjev: `{type: "otp", user, data}`. Pozivatelji nikada ne biraju kanal niti pišu tekst — servis to posjeduje, pa se promjena predloška isporučuje jednom.
- **Tip → politika**: svaki **tip** preslikava se na politiku. *OTP* je visokog prioriteta, SMS+Push, ignorira marketinški opt-out, ističe za 60 s. *Transakcijski* (račun, reset lozinke) je visok, poštuje preferencije kanala. *Marketing* je nizak, bulk traka, strogo poštuje opt-out i tihe sate.
- **Prioritetne trake** su odvojene Kafka topike s odvojenim consumer grupama. Visoka traka ostaje gotovo prazna i prazni se u milisekundama; bulk traka može zaostajati minutama bez utjecaja na latenciju OTP-a. Ovo je najvažnija odluka.
- **Servis preferencija** provjerava se po primatelju: opt-out? tihi sati? per-kanal prekidač? ograničenje učestalosti? Marketing koji krši preferenciju odbacuje se ovdje.
- **Template engine** renderira lokalizirani sadržaj iz verzioniranog predloška + varijabli, pa su tekst i kod razdvojeni.
- **Adapteri kanala** omataju FCM/APNs, SendGrid, Twilio iza jednog sučelja, svaki sa svojim rate limiterom, retryjem i DLQ-om (ista fan-out disciplina kao kod bilo kojeg bulk pošiljatelja).

## Perspektiva intervjua

Ispitivači provjeravaju razdvajate li **odgovornosti (concerns)**: mnogi kandidati grade monolit koji šalje email izravno, a onda otkriju da marketinške poplave odgađaju OTP-ove. Imenovanje *prioritetnih traka*, *provođenja preferencija* i *idempotentnih ključeva* (kako ponovljeni zahtjev ne bi obavijestio dvaput) je senior signal. Dobar dodaje kanale; odličan objašnjava zašto OTP i marketing nikada ne smiju dijeliti queue i kako radi **fallback lanac** (Push padne → SMS).

## Kompromisi i neuspjesi

- **Jedan servis vs po tim**: centralizacija daje dosljedne preferencije, throttling i audit, ali postaje kritična ovisnost — mora biti visoko dostupna (HA), inače prekid OTP-a za prijavu blokira cijelu tvrtku.
- **Real-time vs trošak**: SMS je skup i spor; preferirajte Push/In-App i posežite za SMS-om samo za visokovrijedne tipove.
- **Neuspjeh**: prekid pružatelja pokreće fallback lanac, a ne tvrdi neuspjeh. **Dedup ključevi** sprječavaju da ponovna isporuka iz queuea pošalje OTP dvaput. Pratite SLO-ove isporuke po tipu — odgođeni marketinški email je u redu, odgođeni OTP je incident.

Arhitektura

Komponente i tok

Perspektiva intervjua

Kompromisi i neuspjesi

Povezana pitanja