Hur skulle du designa en företagsövergripande notifikationstjänst?

Question

IT Interview Practice · Accepted Answer

Bygg en tjänst som varje team anropar med en **notifikationstyp + mottagare**, och låt tjänsten lösa kanal, mall, användarpreferenser och prioritet. Det avgörande designgreppet är **prioritetsfiler (priority lanes)** — en OTP kan inte vänta bakom en marknadsföringssändning till 2M användare.

## 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 och flöde

- **Notify API** tar en typad request: `{type: "otp", user, data}`. Anroparen väljer aldrig kanal eller skriver text — tjänsten äger det, så en malländring rullas ut en gång.
- **Typ → policy**: varje **typ** mappar till en policy. *OTP* är högprioriterad, SMS+Push, ignorerar marknadsföringsavregistrering, går ut efter 60s. *Transaktionell* (kvitto, lösenordsåterställning) är hög, respekterar kanalpreferenser. *Marknadsföring* är låg, bulk-fil, hedrar strikt opt-out och quiet hours.
- **Prioritetsfiler** är separata Kafka topics med separata consumer groups. Högfilen förblir nästan tom och töms på millisekunder; bulk-filen kan hopa sig i minuter utan att röra OTP-latensen. Detta är det enskilt viktigaste beslutet.
- **Preferenstjänst** kontrolleras per mottagare: avregistrerad? quiet hours? kanalinställning? frekvenstak? Marknadsföring som bryter mot en preferens släpps här.
- **Mallmotor** renderar lokaliserat innehåll från en versionerad mall + variabler, så att text och kod är frikopplade.
- **Kanaladaptrar** kapslar in FCM/APNs, SendGrid, Twilio bakom ett gränssnitt, var och en med sin egen rate limiter, omförsök och DLQ (samma fan-out-disciplin som vilken bulk-avsändare som helst).

## Intervjuperspektiv

Intervjuare undersöker om du separerar **ansvarsområden**: många kandidater bygger en monolit som skickar e-post direkt, och upptäcker sedan att marknadsföringsfloder försenar OTP:er. Att namnge *prioritetsfiler*, *preferensefterlevnad* och *idempotensnycklar* (så att en omförsökt request inte notifierar dubbelt) är seniorsignalen. Bra lägger till kanaler; utmärkt förklarar varför OTP och marknadsföring aldrig får dela kö och hur en **fallback-kedja** (Push misslyckas → SMS) fungerar.

## Avvägningar och fel

- **En tjänst vs per team**: centralisering ger konsekventa preferenser, strypning och revision, men blir ett kritiskt beroende — den måste vara HA, annars blockerar ett OTP-avbrott vid inloggning hela företaget.
- **Realtid vs kostnad**: SMS är dyrt och långsamt; föredra Push/In-App och fall tillbaka till SMS bara för högvärdiga typer.
- **Fel**: ett leverantörsavbrott utlöser fallback-kedjan, inte ett hårt fel. **Dedup-nycklar** förhindrar att en omleverans i kön skickar en OTP två gånger. Följ upp leverans-SLO:er per typ — ett försenat marknadsföringsmejl är okej, en försenad OTP är en incident.

Arkitektur

Komponenter och flöde

Intervjuperspektiv

Avvägningar och fel

Relaterade frågor