Hvordan ville du designe en virksomhedsdækkende notifikationstjeneste?

Question

IT Interview Practice · Accepted Answer

Byg én tjeneste, som alle teams kalder med en **notifikationstype + modtager**, og lad tjenesten afgøre kanal, template, brugerpræferencer og prioritet. Det centrale designtræk er **priority lanes** — en OTP kan ikke vente bag et marketing-blast til 2M brugere.

## Arkitektur

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

## Komponenter og flow

- **Notify API** modtager en typet request: `{type: "otp", user, data}`. Kaldere vælger aldrig en kanal eller skriver tekst — tjenesten ejer det, så en template-ændring udrulles én gang.
- **Type → policy**: hver **type** mapper til en policy. *OTP* er høj prioritet, SMS+Push, ignorerer marketing-opt-out, udløber efter 60s. *Transaktionel* (kvittering, password-reset) er høj, respekterer kanalpræferencer. *Marketing* er lav, bulk lane, honorerer strengt opt-out og quiet hours.
- **Priority lanes** er separate Kafka topics med separate consumer groups. Den høje lane forbliver næsten tom og drænes på millisekunder; bulk-lanen kan hobe sig op i minutter uden at røre OTP-latency. Dette er den enkeltvigtigste beslutning.
- **Preference service** tjekkes pr. modtager: opted out? quiet hours? kanal-toggle? frequency cap? Marketing der overtræder en præference, droppes her.
- **Template engine** renderer lokaliseret indhold fra en versioneret template + variabler, så tekst og kode er decoupled.
- **Channel adapters** indpakker FCM/APNs, SendGrid, Twilio bag ét interface, hver med sin egen rate limiter, retry og DLQ (samme fan-out-disciplin som enhver bulk-afsender).

## Interview-perspektiv

Interviewere undersøger, om du adskiller **concerns**: mange kandidater bygger en monolit, der sender email direkte, og opdager så, at marketing-oversvømmelser forsinker OTP'er. At navngive *priority lanes*, *preference enforcement* og *idempotency keys* (så en genforsøgt request ikke notificerer dobbelt) er senior-signalet. Godt tilføjer kanaler; fremragende forklarer, hvorfor OTP og marketing aldrig må dele en queue, og hvordan en **fallback-kæde** (Push fejler → SMS) fungerer.

## Trade-offs og fejl

- **Én tjeneste vs pr. team**: centralisering giver konsistente præferencer, throttling og audit, men bliver en kritisk afhængighed — den skal være HA, ellers blokerer et login-OTP-udfald hele virksomheden.
- **Real-time vs omkostning**: SMS er dyrt og langsomt; foretræk Push/In-App og fald kun tilbage til SMS for højværdityper.
- **Fejl**: et provider-udfald udløser fallback-kæden, ikke en hård fejl. **Dedup-nøgler** forhindrer, at en queue-genlevering sender en OTP to gange. Hold delivery-SLO'er pr. type — en forsinket marketing-email er fin, en forsinket OTP er en hændelse.

Arkitektur

Komponenter og flow

Interview-perspektiv

Trade-offs og fejl

Relaterede spørgsmål