Jak byste navrhli firemní notifikační službu pro celou organizaci?

Question

IT Interview Practice · Accepted Answer

Postavte jednu službu, kterou každý tým volá s **typem notifikace + příjemcem**, a nechte službu vyřešit kanál, šablonu, uživatelské preference a prioritu. Klíčovým návrhovým krokem jsou **prioritní pruhy (priority lanes)** — OTP nemůže čekat za marketingovým výbuchem pro 2 miliony uživatelů.

## Architektura

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

## Komponenty a tok

- **Notify API** přijímá typovaný požadavek: `{type: "otp", user, data}`. Volající nikdy nevybírají kanál ani nepíší text — to vlastní služba, takže se změna šablony nasadí jen jednou.
- **Type → policy**: každý **typ** se mapuje na politiku. *OTP* je vysoká priorita, SMS+Push, ignoruje marketingový opt-out, vyprší za 60 s. *Transakční* (účtenka, reset hesla) je vysoká, respektuje preference kanálů. *Marketing* je nízká, bulk lane, striktně dodržuje opt-out a quiet hours.
- **Prioritní pruhy** jsou oddělené Kafka topicy se samostatnými consumer groupami. Vysoký pruh zůstává téměř prázdný a vyprázdní se v milisekundách; bulk pruh se může na minuty zaplnit, aniž by ovlivnil latenci OTP. Toto je jediné nejdůležitější rozhodnutí.
- **Preference service** se kontroluje na příjemce: opt-out? quiet hours? přepínač na kanál? frequency cap? Marketing, který poruší preferenci, se zde zahodí.
- **Template engine** vykreslí lokalizovaný obsah z verzované šablony + proměnných, takže text a kód jsou oddělené.
- **Channel adapters** obalují FCM/APNs, SendGrid, Twilio za jedno rozhraní, každý s vlastním rate limiterem, retry a DLQ (stejná disciplína fan-outu jako u kteréhokoli hromadného odesílatele).

## Pohled z pohovoru

Tazatelé zkoumají, zda oddělujete **concerns**: mnoho kandidátů postaví monolit, který posílá email přímo, a pak zjistí, že marketingové záplavy zdrží OTP. Pojmenování *prioritních pruhů*, *vynucování preferencí* a *idempotenčních klíčů* (aby zopakovaný požadavek nenotifikoval dvakrát) je seniorní signál. Dobré přidá kanály; skvělé vysvětlí, proč OTP a marketing nikdy nesmí sdílet frontu a jak funguje **fallback řetězec** (Push selže → SMS).

## Kompromisy a selhání

- **Jedna služba vs na tým**: centralizace dá konzistentní preference, throttling a audit, ale stane se kritickou závislostí — musí být HA, jinak výpadek login OTP zablokuje celou firmu.
- **Real-time vs náklady**: SMS je drahá a pomalá; preferujte Push/In-App a k SMS sáhněte jen u vysoce hodnotných typů.
- **Selhání**: výpadek poskytovatele spustí fallback řetězec, nikoli tvrdé selhání. **Dedup klíče** zabrání, aby znovudoručení z fronty odeslalo OTP dvakrát. Sledujte SLO doručení na typ — zpožděný marketingový email je v pořádku, zpožděné OTP je incident.

Architektura

Komponenty a tok

Pohled z pohovoru

Kompromisy a selhání

Související otázky