Wie würdest du einen unternehmensweiten Notification-Service entwerfen?

Question

IT Interview Practice · Accepted Answer

Baue einen Dienst, den jedes Team mit einem **Notification-Typ + Empfänger** aufruft, und lass den Dienst Channel, Template, Nutzerpräferenzen und Priorität auflösen. Der zentrale Entwurfszug sind **Priority Lanes** - ein OTP darf nicht hinter einem Marketing-Blast an 2 Mio. Nutzer warten.

## Architektur

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

## Komponenten und Ablauf

- **Notify API** nimmt einen typisierten Request entgegen: `{type: "otp", user, data}`. Aufrufer wählen nie einen Channel oder schreiben Texte - der Dienst besitzt das, sodass eine Template-Änderung nur einmal ausgeliefert wird.
- **Typ → Policy**: Jeder **Typ** wird auf eine Policy abgebildet. *OTP* ist hochpriorisiert, SMS+Push, ignoriert Marketing-Opt-out, verfällt nach 60s. *Transactional* (Beleg, Passwort-Reset) ist hoch, respektiert Channel-Präferenzen. *Marketing* ist niedrig, Bulk Lane, hält strikt Opt-out und Ruhezeiten ein.
- **Priority Lanes** sind separate Kafka-Topics mit separaten Consumer Groups. Die High Lane bleibt nahezu leer und leert sich in Millisekunden; die Bulk Lane kann minutenlang aufstauen, ohne die OTP-Latency zu berühren. Das ist die mit Abstand wichtigste Entscheidung.
- **Preference Service** wird pro Empfänger geprüft: Opt-out? Ruhezeiten? Per-Channel-Toggle? Frequency Cap? Marketing, das eine Präferenz verletzt, wird hier verworfen.
- **Template Engine** rendert lokalisierte Inhalte aus einem versionierten Template + Variablen, sodass Text und Code entkoppelt sind.
- **Channel Adapter** kapseln FCM/APNs, SendGrid, Twilio hinter einer Schnittstelle, jeder mit eigenem Rate Limiter, Retry und DLQ (dieselbe Fan-out-Disziplin wie bei jedem Bulk-Sender).

## Interview-Perspektive

Interviewer prüfen, ob du **Concerns** trennst: Viele Kandidaten bauen einen Monolithen, der direkt E-Mails sendet, und entdecken dann, dass Marketing-Fluten OTPs verzögern. *Priority Lanes*, *Preference Enforcement* und *Idempotency Keys* (damit ein wiederholter Request nicht doppelt benachrichtigt) zu benennen, ist das Senior-Signal. Gut ergänzt Channels; hervorragend erklärt, warum OTP und Marketing nie eine Queue teilen dürfen und wie eine **Fallback-Kette** (Push scheitert → SMS) funktioniert.

## Trade-offs und Fehlerfälle

- **Ein Dienst vs. pro Team**: Zentralisierung liefert konsistente Präferenzen, Throttling und Audit, wird aber zur kritischen Abhängigkeit - er muss hochverfügbar sein, sonst blockiert ein Login-OTP-Ausfall das ganze Unternehmen.
- **Echtzeit vs. Kosten**: SMS ist teuer und langsam; bevorzuge Push/In-App und weiche nur bei hochwertigen Typen auf SMS aus.
- **Fehlerfall**: Ein Provider-Ausfall löst die Fallback-Kette aus, kein hartes Scheitern. **Dedup-Keys** verhindern, dass eine erneute Queue-Zustellung ein OTP zweimal sendet. Verfolge Delivery-SLOs pro Typ - eine verzögerte Marketing-E-Mail ist okay, ein verzögertes OTP ist ein Vorfall.

Architektur

Komponenten und Ablauf

Interview-Perspektive

Trade-offs und Fehlerfälle

Ähnliche Fragen