Hoe zou je een bedrijfsbrede notificatieservice ontwerpen?

Question

IT Interview Practice · Accepted Answer

Bouw één service die elk team aanroept met een **notificatietype + ontvanger**, en laat de service kanaal, template, gebruikersvoorkeuren en prioriteit bepalen. De sleutelbeslissing in het ontwerp zijn **priority lanes** — een OTP kan niet achter een marketingblast van 2 miljoen gebruikers wachten.

## Architectuur

```text
Services ─▶ Notify API ─▶ [valideer + verrijk] ─▶ 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)
```

## Componenten en flow

- **Notify API** neemt een getypeerde request: `{type: "otp", user, data}`. Aanroepers kiezen nooit een kanaal en schrijven geen tekst — de service bezit dat, zodat een templatewijziging één keer wordt uitgerold.
- **Type → policy**: elk **type** mapt naar een policy. *OTP* is hoge prioriteit, SMS+Push, negeert marketing-opt-out, verloopt in 60s. *Transactioneel* (bon, wachtwoordreset) is hoog, respecteert kanaalvoorkeuren. *Marketing* is laag, bulk lane, houdt strikt opt-out en stille uren aan.
- **Priority lanes** zijn aparte Kafka topics met aparte consumer groups. De high lane blijft vrijwel leeg en draineert in milliseconden; de bulk lane kan minuten oplopen zonder de OTP-latency te raken. Dit is de belangrijkste enkele beslissing.
- **Preference service** wordt per ontvanger gecontroleerd: opgezegd? stille uren? per-kanaal-toggle? frequency cap? Marketing die een voorkeur schendt, wordt hier gedropt.
- **Template engine** rendert gelokaliseerde content uit een geversioneerde template + variabelen, zodat tekst en code ontkoppeld zijn.
- **Channel adapters** verpakken FCM/APNs, SendGrid, Twilio achter één interface, elk met eigen rate limiter, retry en DLQ (dezelfde fan-out-discipline als elke bulk sender).

## Interviewperspectief

Interviewers peilen of je **concerns** scheidt: veel kandidaten bouwen een monoliet die direct e-mail verstuurt en ontdekken dan dat marketingvloeden OTP's vertragen. Het benoemen van *priority lanes*, *afdwinging van voorkeuren* en *idempotency keys* (zodat een herhaalde request niet dubbel notificeert) is het senior-signaal. Goed voegt kanalen toe; uitstekend legt uit waarom OTP en marketing nooit een queue mogen delen en hoe een **fallback chain** (Push faalt → SMS) werkt.

## Afwegingen en faalmodi

- **Eén service versus per-team**: centraliseren geeft consistente voorkeuren, throttling en audit, maar wordt een kritieke afhankelijkheid — het moet HA zijn, anders blokkeert een OTP-storing bij het inloggen het hele bedrijf.
- **Real-time versus kosten**: SMS is duur en traag; geef de voorkeur aan Push/In-App en val alleen terug op SMS voor hoogwaardige types.
- **Faalmodus**: een provider-storing triggert de fallback chain, geen harde fail. **Dedup keys** voorkomen dat een queue-herbezorging een OTP twee keer verstuurt. Volg per-type delivery-SLO's — een vertraagde marketingmail is prima, een vertraagde OTP is een incident.

Architectuur

Componenten en flow

Interviewperspectief

Afwegingen en faalmodi

Gerelateerde vragen