Hvordan ville du designet en bedriftsomfattende varslingstjeneste?

Question

IT Interview Practice · Accepted Answer

Bygg én tjeneste som hvert team kaller med en **varslingstype + mottaker**, og la tjenesten løse kanal, template, brukerpreferanser og prioritet. Det avgjørende designgrepet er **prioritetsbaner** — en OTP kan ikke vente bak en marketing-blast til 2M brukere.

## Arkitektur

```text
Tjenester ─▶ Notify API ─▶ [valider + berik] ─▶ Kafka-topics
                                                 ├─ otp/txn  (høy bane)
                                                 └─ marketing (bulk-bane)
                                                      │
                            ┌──── Dispatcher (per bane) ────┐
                            │ prefs-sjekk ─▶ template-render │
                            └────┬──────┬──────┬────────────┘
                              Push   Email   SMS   In-App
                                 (provider-adaptere + rate limit)
```

## Komponenter og flyt

- **Notify API** tar en typet request: `{type: "otp", user, data}`. Callere velger aldri en kanal eller skriver tekst — tjenesten eier det, så en template-endring rulles ut én gang.
- **Type → policy**: hver **type** mapper til en policy. *OTP* er høyprioritet, SMS+Push, ignorerer marketing-opt-out, utløper om 60s. *Transaksjonell* (kvittering, passord-reset) er høy, respekterer kanalpreferanser. *Marketing* er lav, bulk-bane, følger strengt opt-out og quiet hours.
- **Prioritetsbaner** er separate Kafka-topics med separate consumer-grupper. Den høye banen holder seg nær tom og tømmes på millisekunder; bulk-banen kan hope seg opp i minutter uten å påvirke OTP-latency. Dette er den enkeltviktigste beslutningen.
- **Preferansetjeneste** sjekkes per mottaker: opted out? quiet hours? per-kanal-toggle? frekvenstak? Marketing som bryter en preferanse droppes her.
- **Template-motor** rendrer lokalisert innhold fra en versjonert template + variabler, slik at tekst og kode er avkoblet.
- **Kanaladaptere** pakker FCM/APNs, SendGrid, Twilio bak ett grensesnitt, hver med sin egen rate limiter, retry og DLQ (samme fan-out-disiplin som enhver bulk-avsender).

## Intervjuperspektiv

Intervjuere undersøker om du separerer **ansvarsområder**: mange kandidater bygger en monolitt som sender e-post direkte, og oppdager så at marketing-flommer forsinker OTP-er. Å navngi *prioritetsbaner*, *preferansehåndhevelse* og *idempotensnøkler* (slik at en retried request ikke dobbeltvarsler) er senior-signalet. Bra legger til kanaler; utmerket forklarer hvorfor OTP og marketing aldri må dele en kø og hvordan en **fallback-kjede** (Push feiler → SMS) fungerer.

## Avveininger og feil

- **Én tjeneste vs per-team**: sentralisering gir konsistente prefs, throttling og audit, men blir en kritisk avhengighet — den må være HA, ellers blokkerer et login-OTP-utfall hele selskapet.
- **Sanntid vs kostnad**: SMS er dyrt og tregt; foretrekk Push/In-App og fall tilbake til SMS bare for høyverdi-typer.
- **Feil**: et leverandørutfall trigger fallback-kjeden, ikke en hard feil. **Dedup-nøkler** hindrer at en kø-redelivery sender en OTP to ganger. Spor leverings-SLO-er per type — en forsinket marketing-e-post er greit, en forsinket OTP er en hendelse.

Arkitektur

Komponenter og flyt

Intervjuperspektiv

Avveininger og feil

Relaterte spørsmål