Echtzeit-Benachrichtigungsdienst — Systementwurf auf hoher Ebene

================================================================================
0. ÜBERSCHLAGSRECHNUNG

• 10 Mio. täglich aktive Nutzer × 20 Benachrichtigungen/Nutzer/Tag = 200 Mio. Benachrichtigungen/Tag
• 200 Mio. / 86.400 s ≈ 2.315 Benachrichtigungen pro Sekunde (im Mittel)
• Spitzenlast (angenommen 5× Mittelwert) ≈ 11.575 Benachrichtigungen pro Sekunde
• Nutzlast je Benachrichtigung ca. 1 KB → ca. 200 GB/Tag an Rohdaten
• Latenzbudget: unter 2 Sekunden Ende-zu-Ende (Aufnahme → Zustellung auf dem Gerät)

================================================================================

1. KERNARCHITEKTUR
   ================================================================================

Das System folgt einer ereignisgetriebenen Microservice-Architektur mit diesen Kernbausteinen:

┌──────────────┐
│ Producers │ (Post Service, Like Service, Comment Service, Follow Service, etc.)
└──────┬───────┘
│ Notification Event (gRPC / async message)
▼
┌──────────────────┐
│ API Gateway / │ Rate limiting, authentication, routing
│ Load Balancer │ (e.g., AWS ALB / Envoy / Kong)
└──────┬───────────┘
│
▼
┌──────────────────┐
│ Notification │ Stateless service (horizontally scalable)
│ Service (NS) │ - Validates & deduplicates events
│ │ - Enriches with user preferences
│ │ - Fans out to per-channel queues
└──────┬───────────┘
│ Writes notification record to DB
│ Publishes to Message Queue
▼
┌──────────────────────────────────────────────────┐
│ Message Queue / Broker │
│ (Apache Kafka — partitioned by user_id hash) │
│ │
│ Topics: push_notifications │
│ email_notifications │
│ in_app_notifications │
└──┬──────────────┬─────────────────┬──────────────┘
│ │ │
▼ ▼ ▼
┌────────┐ ┌──────────┐ ┌────────────────┐
│ Push │ │ Email │ │ In-App │
│ Worker │ │ Worker │ │ Worker │
│ Pool │ │ Pool │ │ Pool │
└───┬────┘ └────┬─────┘ └───────┬────────┘
│ │ │
▼ ▼ ▼
┌────────┐ ┌──────────┐ ┌────────────────┐
│ APNs / │ │ SES / │ │ WebSocket │
│ FCM │ │ SendGrid │ │ Gateway │
└────────┘ └──────────┘ │ (persistent │
│ connections) │
└────────────────┘

Beschreibung der Komponenten:

A) API Gateway / Load Balancer

• Einstiegspunkt für interne Producer-Dienste und externe API-Aufrufe (etwa „als gelesen markieren").
• Übernimmt Ratenbegrenzung, Authentifizierung und Routing.
• Verteilt den Verkehr auf mehrere Instanzen des Notification Service.

B) Notification Service (NS)

• Zustandsloser Microservice, in mehreren Replikaten hinter dem Load Balancer betrieben.
• Nimmt Benachrichtigungsereignisse entgegen, validiert sie und dedupliziert sie (Prüfung des Idempotenzschlüssels).
• Liest die Benachrichtigungseinstellungen aus einem Cache (Redis) oder der Datenbank.
• Bestimmt anhand der Einstellungen die Zustellkanäle (Push, E-Mail, In-App).
• Schreibt den Benachrichtigungsdatensatz in die Datenbank.
• Veröffentlicht kanalspezifische Nachrichten in Kafka-Topics.

C) Message Queue (Apache Kafka)

• Entkoppelt Erzeugung und Zustellung und fängt Lastspitzen ab.
• Partitioniert nach user_id-Hash, um die Reihenfolge je Nutzerin und Nutzer zu wahren.
• Bietet Dauerhaftigkeit (Replikationsfaktor 3) und die Möglichkeit zum erneuten Abspielen.
• Getrennte Topics je Kanal erlauben die unabhängige Skalierung der Konsumenten.

D) Kanalarbeiter (Consumer Groups)

• Push Worker Pool: konsumiert aus push_notifications, bündelt Anfragen und sendet an APNs (iOS) und FCM (Android). Verwaltet Tokens und die Wiederholungslogik.
• Email Worker Pool: konsumiert aus email_notifications, rendert Vorlagen und versendet über SES/SendGrid. Nutzt exponentielles Backoff bei vorübergehenden Fehlern.
• In-App Worker Pool: konsumiert aus in_app_notifications und übergibt an das WebSocket Gateway zur Echtzeitzustellung. Weicht auf Polling aus, wenn die WebSocket-Verbindung getrennt ist.

E) WebSocket Gateway

• Hält dauerhafte WebSocket-Verbindungen zu Nutzerinnen und Nutzern, die online sind.
• Horizontal skaliert; nutzt Redis Pub/Sub oder einen gemeinsamen Message Bus, sodass jeder Gateway-Knoten an jede verbundene Person zustellen kann.
• Das Verbindungsregister liegt in Redis (Zuordnung user_id → gateway_node).

F) Notification Read API

• Getrennter Lesepfad zum Abrufen der Benachrichtigungshistorie, zum Markieren als gelesen und zum Verwalten der Einstellungen.
• Wird aus Lesereplikaten bzw. dem Cache bedient, um den Schreibpfad nicht zu beeinträchtigen.

================================================================================
2. DATENBANKSCHEMA

Primärer Datenspeicher: PostgreSQL (für Einstellungen und Metadaten) + Cassandra (für die Benachrichtigungsspeicherung im großen Maßstab).

--- PostgreSQL (Benutzereinstellungen und Metadaten) ---

TABLE: users
user_id UUID PRIMARY KEY
email VARCHAR(255)
phone VARCHAR(50)
created_at TIMESTAMP
updated_at TIMESTAMP

TABLE: notification_preferences
user_id UUID PRIMARY KEY REFERENCES users(user_id)
push_enabled BOOLEAN DEFAULT TRUE
email_enabled BOOLEAN DEFAULT TRUE
in_app_enabled BOOLEAN DEFAULT TRUE
quiet_hours_start TIME NULLABLE
quiet_hours_end TIME NULLABLE
email_digest_freq ENUM('instant', 'hourly', 'daily') DEFAULT 'instant'
-- Overrides je Kategorie
likes_push BOOLEAN DEFAULT TRUE
likes_email BOOLEAN DEFAULT FALSE
comments_push BOOLEAN DEFAULT TRUE
comments_email BOOLEAN DEFAULT TRUE
follows_push BOOLEAN DEFAULT TRUE
follows_email BOOLEAN DEFAULT FALSE
mentions_push BOOLEAN DEFAULT TRUE
mentions_email BOOLEAN DEFAULT TRUE
updated_at TIMESTAMP

TABLE: device_tokens
token_id UUID PRIMARY KEY
user_id UUID REFERENCES users(user_id)
platform ENUM('ios', 'android', 'web')
device_token VARCHAR(512)
is_active BOOLEAN DEFAULT TRUE
created_at TIMESTAMP
updated_at TIMESTAMP
INDEX idx_device_user (user_id)

--- Cassandra (Benachrichtigungsspeicher — auf Zeitreihenlesevorgänge optimiert) ---

TABLE: notifications
user_id UUID -- Partitionsschlüssel
created_at TIMEUUID -- Clustering-Schlüssel (DESC)
notification_id UUID
type TEXT -- 'like', 'comment', 'follow', 'mention', 'system'
actor_id UUID
target_entity_type TEXT -- 'post', 'comment', 'profile'
target_entity_id UUID
message TEXT
is_read BOOLEAN
channels_delivered SET<TEXT> -- {'push', 'email', 'in_app'}
metadata TEXT -- JSON-Blob für Erweiterbarkeit
PRIMARY KEY ((user_id), created_at)
WITH CLUSTERING ORDER BY (created_at DESC)
AND default_time_to_live = 7776000 -- TTL von 90 Tagen

TABLE: notification_counts (materialisierte Zähltabelle)
user_id UUID PRIMARY KEY
unread_count COUNTER

--- Redis (Cache-Schicht) ---

• Cache der Einstellungen: Key = pref:{user_id}, TTL = 10 Min.
• Cache der ungelesenen Anzahl: Key = unread:{user_id}, TTL = 5 Min.
• Deduplizierungsmenge: Key = dedup:{idempotency_key}, TTL = 24 Stunden
• Register der WebSocket-Verbindungen: Key = ws:{user_id} → gateway_node_id

================================================================================
3. SKALIERUNGSSTRATEGIE

A) Horizontale Skalierung der zustandslosen Dienste

• Notification Service, sämtliche Worker Pools und das WebSocket Gateway sind zustandslos und horizontal skalierbar.
• Autoscaling-Gruppen (Kubernetes HPA) anhand von CPU, Speicher und Queue-Lag.
• Zielwert: je NS-Instanz etwa 500 Anfragen/s; in der Spitze werden rund 25 Instanzen benötigt.

B) Kafka-Partitionierung

• Start mit 64 Partitionen je Topic (erlaubt bis zu 64 Konsumenten je Gruppe).
• Partitionierung nach user_id-Hash für die Reihenfolgegarantie je Person.
• Partitionen mit wachsendem Durchsatz erhöhen (Re-Partitionierung mit Bedacht).
• Getrennte Consumer Groups je Kanal ermöglichen unabhängige Skalierung.

C) Datenbankskalierung

• Cassandra: von Natur aus horizontal skalierbar. Start mit einem Cluster aus 6 Knoten (RF=3).
  Knoten mit wachsendem Datenvolumen ergänzen. Der Partitionsschlüssel user_id verteilt die Last gleichmäßig.
• PostgreSQL: für die Einstellungen zunächst vertikale Skalierung (verhältnismäßig kleiner Datenbestand: 10 Mio. Zeilen).
  Lesereplikate für die leselastigen Abfragen der Einstellungen ergänzen. Bei Bedarf Sharding nach user_id erwägen.
• Redis Cluster: 3 oder mehr Knoten mit automatischem Sharding für Cache und Verbindungsregister.

D) Skalierung des WebSocket Gateways

• Jeder Gateway-Knoten trägt etwa 100.000 gleichzeitige Verbindungen.
• 10 Mio. täglich aktive Nutzer bei etwa 30 % gleichzeitig online = 3 Mio. Verbindungen → rund 30 Gateway-Knoten.
• Redis Pub/Sub oder ein leichtgewichtiger Message Bus (etwa NATS) für das Routing zwischen den Knoten.
• Konsistentes Hashing für die Zuordnung Person zu Knoten, mit sanftem Rebalancing.

E) Ratenbegrenzung und Gegendruck

• Die Producer werden begrenzt, um Missbrauch zu verhindern (etwa höchstens 1000 Ereignisse/s je Producer).
• Überwachung des Kafka-Consumer-Lags mit Alarmen; Konsumenten skalieren automatisch, sobald der Lag einen Schwellenwert überschreitet.
• Circuit Breaker vor externen Diensten (APNs, FCM, SES), um Kaskadenausfälle zu verhindern.

F) Pfad für künftiges Wachstum

• Umstellung auf einen Betrieb über mehrere Regionen mit Kafka MirrorMaker 2 für die regionsübergreifende Replikation.
• Einführung einer Schicht zur Bündelung von Benachrichtigungen (etwa „X und 5 weitere gefällt dein Beitrag").
• Ergänzung einer Prioritätsqueue für zeitkritische Benachrichtigungen (Direktnachrichten gegenüber Like-Benachrichtigungen).

================================================================================
4. ZUVERLÄSSIGKEIT UND FEHLERTOLERANZ

A) Datenhaltbarkeit

• Kafka: Replikationsfaktor 3, min.insync.replicas = 2, acks = all.
  Garantiert Datenerhalt auch beim Ausfall eines Brokers.
• Cassandra: Replikationsfaktor 3, Schreibkonsistenz QUORUM (2 von 3).
  Verkraftet den Ausfall eines einzelnen Knotens ohne Datenverlust.
• PostgreSQL: synchrone Replikation auf mindestens einen Standby.

B) Zustellung mindestens einmal

• Kafka-Konsumenten schreiben Offsets erst nach erfolgreicher Verarbeitung fest.
• Die Worker stellen idempotent zu und nutzen notification_id als Dedup-Schlüssel.
• Scheitert eine Push- oder E-Mail-Zustellung, verbleibt die Nachricht für einen erneuten Versuch in Kafka.
• Eine Dead Letter Queue (DLQ) nimmt Nachrichten auf, die nach N Versuchen scheitern (etwa 5 Versuche mit exponentiellem Backoff).

C) Hochverfügbarkeit (Ziel 99,9 % = höchstens 8,76 Stunden Ausfall pro Jahr)

• Alle Dienste laufen über drei Availability Zones (AZs) verteilt.
• Kubernetes verteilt die Replikate über Pod-Anti-Affinity-Regeln auf die Zonen.
• Die Datenbankcluster erstrecken sich über mehrere AZs mit automatischem Failover.
• Health Checks des Load Balancers entfernen ungesunde Instanzen automatisch.
• Blue-Green- oder Canary-Deployments, um Ausfallzeiten beim Ausrollen gering zu halten.

D) Geordnete Verschlechterung

• Fällt der Push-Dienst (APNs/FCM) aus, werden Benachrichtigungen in Kafka eingereiht und später erneut versucht.
• Ist das WebSocket Gateway überlastet, weichen die Clients auf das Abfragen der Notification Read API aus.
• Ist Cassandra vorübergehend nicht erreichbar, werden Benachrichtigungen in Kafka gepuffert (dessen Aufbewahrung mehrere Tage beträgt).
• Circuit-Breaker-Muster vor allen externen Abhängigkeiten, mit definiertem Rückfallverhalten.

E) Überwachung und Alarmierung

• Verfolgung der Ende-zu-Ende-Latenz: Zeitstempel bei Erzeugung → Zeitstempel bei Zustellung (P50, P95, P99).
• Überwachung des Kafka-Consumer-Lags je Topic und Consumer Group.
• Dashboards zur Fehlerrate je Kanal (Push-Fehlerquote, E-Mail-Bounce-Rate).
• Alarm bei: Latenz über 2 s im P95, Consumer-Lag über 10.000 Nachrichten, Fehlerrate über 1 %, Verfügbarkeit unter 99,9 %.

F) Notfallwiederherstellung

• Kafka-Topic-Daten werden 7 Tage vorgehalten, sodass ab jedem Punkt erneut abgespielt werden kann.
• Tägliche Cassandra-Snapshots, abgelegt in S3 mit regionsübergreifender Replikation.
• PostgreSQL-WAL-Archivierung nach S3 für Point-in-Time-Recovery.
• Runbook für die vollständige Cluster-Wiederherstellung mit Zielwerten RTO unter 1 Stunde und RPO unter 5 Minuten.

================================================================================
5. WESENTLICHE ABWÄGUNGEN

Abwägung 1: Verfügbarkeit gegen strenge Konsistenz (AP statt CP)

Entscheidung: Für Zustellung und Lesestatus wurde eventuelle Konsistenz gewählt.

• Cassandra mit QUORUM-Schreibvorgängen bietet für Benachrichtigungen eine hinreichend starke Konsistenz und stellt zugleich Verfügbarkeit und Partitionstoleranz in den Vordergrund.
• Es kann kurzzeitig eine veraltete Anzahl ungelesener Nachrichten angezeigt werden (in Redis mit 5 Minuten TTS zwischengespeichert). Für ein Benachrichtigungssystem ist das vertretbar, da eine in Echtzeit exakte Zählung nicht entscheidend ist.
• Die Alternative — sämtliche Benachrichtigungen in einer streng konsistenten Datenbank wie PostgreSQL zu halten — würde bei 200 Mio. Schreibvorgängen pro Tag einen Skalierungsengpass erzeugen und die Verfügbarkeit bei Netzpartitionen gefährden.
• Auswirkung: Gelegentlich weicht die angezeigte Anzahl für einige Sekunden um 1–2 ab. Das ist ein geringfügiger Nachteil gegenüber dem Risiko, dass das gesamte Benachrichtigungssystem ausfällt.

Abwägung 2: Push-Modell (WebSockets) gegen Pull-Modell (Polling) für In-App-Benachrichtigungen

Entscheidung: Push zuerst über WebSockets, mit Polling als Rückfallebene.

• Push über WebSockets stellt in Echtzeit zu (unter einer Sekunde) und erfüllt damit die Vorgabe von unter 2 Sekunden.
• Millionen dauerhafter Verbindungen zu halten, ist jedoch ressourcenintensiv (rund 30 Gateway-Knoten für 3 Mio. gleichzeitige Verbindungen) und erhöht den Betriebsaufwand (Verbindungsverwaltung, Heartbeats, Wiederverbindungslogik).
• Die Alternative — reines Polling — wäre einfacher zu betreiben, würde aber entweder die Latenz erhöhen (bei langem Abfrageintervall) oder die Serverlast drastisch steigern (bei kurzem Intervall). Bei 3 Mio. gleichzeitigen Nutzenden und einer Abfrage alle 2 Sekunden ergäben sich allein dafür 1,5 Mio. Anfragen/s — weit teurer, als WebSocket-Verbindungen zu halten.
• Kompromiss: WebSockets für Online-Nutzende, Rückfall auf Polling (mit längeren Intervallen), wenn keine WebSocket-Verbindung zustande kommt (etwa hinter restriktiven Firewalls). Ist jemand offline, greifen Push-Benachrichtigungen über APNs/FCM.

Abwägung 3: Ein einziger Benachrichtigungsspeicher (Cassandra) gegen mehrere Datenbanktypen

Entscheidung: Cassandra für die Benachrichtigungen und PostgreSQL für Einstellungen und Metadaten, statt einer einzigen Datenbank für alles.

• Cassandra ist stark bei durchsatzintensiven Zeitreihenschreibvorgängen (200 Mio./Tag) und bei Lesevorgängen über den Partitionsschlüssel (Benachrichtigungen einer Person abrufen) — genau das vorherrschende Zugriffsmuster.
• PostgreSQL passt besser zur relationalen Natur der Einstellungen (Joins mit der Benutzertabelle, transaktionale Aktualisierungen).
• Der Preis ist ein höherer Betriebsaufwand (zwei Datenbanksysteme betreiben, überwachen und sichern) sowie die Notwendigkeit, die Daten systemübergreifend konsistent zu halten (wird ein Konto gelöscht, müssen die Benachrichtigungen in Cassandra bereinigt werden).
• Abgefedert wird das durch einen ereignisgesteuerten Aufräumprozess: Löschereignisse stoßen asynchrone Bereinigungsjobs in Cassandra an.

Abwägung 4: Mindestens einmal gegen genau einmal

Entscheidung: Semantik „mindestens einmal" mit Deduplizierung auf Anwendungsebene.

• Eine Zustellung genau einmal über verteilte Systeme hinweg ist extrem aufwendig und komplex (sie erfordert verteilte Transaktionen oder die Exactly-once-Semantik von Kafka mit erheblichen Leistungseinbußen).
• „Mindestens einmal" ist einfacher und leistungsfähiger. Doppelte Benachrichtigungen werden auf Anwendungsebene über Idempotenzschlüssel abgefangen (notification_id wird vor der Zustellung geprüft).
• Das Risiko besteht darin, dass in seltenen Fehlerfällen eine doppelte Push-Benachrichtigung ankommt. Das ist eine kleine Unannehmlichkeit gegenüber verlorenen Benachrichtigungen („höchstens einmal") oder dem Komplexitäts- und Leistungspreis von „genau einmal".

================================================================================
ZUSAMMENFASSUNG

Dieser Entwurf bewältigt 200 Mio. Benachrichtigungen pro Tag über drei Kanäle mit einer Zustelllatenz unter zwei Sekunden. Die ereignisgetriebene Architektur mit Kafka als zentralem Nervensystem sorgt für Dauerhaftigkeit, Entkopplung und natürlichen Gegendruck. Cassandra liefert einen horizontal skalierbaren Benachrichtigungsspeicher, während das WebSocket Gateway die Zustellung in Echtzeit in der App ermöglicht. Auf 99,9 % Verfügbarkeit ist das System durch den Betrieb über mehrere Availability Zones, Replikation auf jeder Ebene und Muster zur geordneten Verschlechterung ausgelegt. Die wesentlichen Abwägungen bevorzugen Verfügbarkeit, Skalierbarkeit und betriebliche Einfachheit gegenüber strenger Konsistenz und Exactly-once-Semantik — für ein Benachrichtigungssystem, in dem gelegentliche Verzögerungen oder seltene Doubletten hinnehmbar sind, ist das die angemessene Wahl.

Hochrangiges Design

1. Kernarchitektur

Ein gutes Design ist ereignisgesteuert, kanalbewusst und primär auf Dauerhaftigkeit ausgelegt.

Hauptablauf

• Produktdienste wie Likes, Kommentare, Follows, Erwähnungen, Nachrichten veröffentlichen ereigniswürdige Benachrichtigungen.
• API Gateway oder interne Event Ingestion API empfangen bei Bedarf direkte Anfragen, aber der meiste Datenverkehr sollte von internen Ereignisströmen stammen.
• Der Notification Orchestrator validiert das Ereignis, dedupliziert es, erweitert die Empfänger, prüft Benutzereinstellungen, erstellt einen dauerhaften Benachrichtigungsdatensatz und gibt Aufträge zur Kanalzustellung aus.
• Message Queue / Event Bus puffert Arbeit für nachgelagerte Kanal-Worker.
• Channel Worker verarbeiten Push-, E-Mail- und In-App-Zustellung unabhängig voneinander.
• Der Delivery Status Service aktualisiert den Benachrichtigungsstatus und versucht bei Bedarf erneut.
• Read APIs dienen dem Benachrichtigungs-Posteingang und den ungelesenen Zählungen für Clients.
• WebSocket / SSE Gateway kann In-App-Updates in Echtzeit an Online-Benutzer pushen.

Wichtige Komponenten

• API Gateway

  • Authentifizierung, Ratenbegrenzung, Routing, Beobachtbarkeit.
  • Wird für Client-Read-APIs und Admin-APIs verwendet.

• Event Bus / Ingestion Stream

  • Durable Log im Kafka/Pulsar-Stil.
  • Produzenten: Social Graph, Content, Messaging, Moderation usw.
  • Topic partitioniert nach recipient_user_id, um die Reihenfolge pro Benutzer zu erhalten, wenn nützlich.

• Notification Orchestrator

  • Statusloser Dienst, der Ereignisse konsumiert.
  • Verantwortlichkeiten:
    • Schema validieren
    • Idempotenzprüfung mittels event_id oder dedupe key
    • Fanout-Entscheidung
    • Präferenzabruf
    • Vorlagenauswahl
    • Prioritätsklassifizierung
    • Persistenz des kanonischen Benachrichtigungsdatensatzes
    • Enqueue von Zustellungsaufgaben pro Kanal
  • Schreibt zuerst, plant dann die Zustellung, damit keine Daten verloren gehen.

• Preference Service

  • Gibt benutzerspezifische Kanaleinstellungen, Ruhezeiten, Geräte-Tokens, Gebietsschema, E-Mail-Verifizierungsstatus zurück.
  • Gesichert durch einen stark konsistenten Benutzereinstellungs-Speicher plus Cache.

• Notification Store

  • Kanonischer, dauerhafter Speicher für Benachrichtigungsmetadaten und Benutzereingangspostfächer.
  • Optimiert für Schreibvorgänge und aktuelle Lesevorgänge.

• Delivery Queue

  • Separate Warteschlangen/Topics pro Kanal: Push, E-Mail, In-App.
  • Ermöglicht unterschiedliche Wiederholungs- und Durchsatzrichtlinien.

• Push Worker

  • Integriert sich mit APNS/FCM.
  • Behandelt Token-Invalidierung, plattformspezifische Payloads, exponentielles Backoff.

• Email Worker

  • Integriert sich mit dem E-Mail-Anbieter.
  • Niedrigere Priorität als Push/In-App für die meisten sozialen Ereignisse.
  • Verfolgt Bounces, Beschwerden, Unterdrückungslisten.

• In-App Delivery Worker

  • Schreibt in den Inbox-Speicher und pusht über WebSocket/SSE, wenn der Benutzer online ist.
  • Wenn offline, bleibt die Benachrichtigung über den Abruf aus der Inbox-API verfügbar.

• Real-Time Gateway

  • Pflegt persistente Client-Verbindungen für aktive Benutzer.
  • Abonniert In-App-Zustellungsereignisse und sendet innerhalb von 2 Sekunden.

• Read API / Inbox Service

  • Benachrichtigungen auflisten, als gelesen markieren, ungelesene Zählung, Paginierung.
  • Liest aus dem Benachrichtigungs-Inbox-Speicher und Cache.

• Retry / Dead Letter Processor

  • Wiederholt transiente Fehler.
  • DLQ für Poison-Nachrichten oder permanente Fehler.
  • Unterstützt Replay.

• Observability Stack

  • Metriken: Latenz von der Einreihung bis zur Zustellung, Erfolgsrate pro Kanal, Wiederholungsanzahl, Warteschlangenverzögerung.
  • Protokolle und verteilte Tracing.
  • Alarmierung bei SLA-Verletzungen.

Interaktionssequenz

• Ein Kommentar-Dienst gibt ein CommentCreated-Ereignis aus.
• Der Event Bus speichert das Ereignis dauerhaft.
• Der Notification Orchestrator verarbeitet das Ereignis, ermittelt den Empfängerbenutzer, prüft die Einstellungen, erstellt eine Benachrichtigungszeile und gibt Aufträge aus an:
  • In-App-Warteschlange
  • Push-Warteschlange, wenn aktiviert und dringend genug
  • E-Mail-Warteschlange, wenn konfiguriert
• Der In-App-Worker speichert den Inbox-Eintrag und pusht über WebSocket, wenn der Benutzer online ist.
• Der Push-Worker sendet an FCM/APNS.
• Zustellungsbestätigungen/Statusaktualisierungen werden zurückgeschrieben.
• Der Benutzer kann den vollständigen Posteingang über die Read API abrufen.

Durchsatzschätzung

• 10 Mio. DAU × 20 Benachrichtigungen/Tag = 200 Mio. Benachrichtigungen/Tag.
• Durchschnittlicher Durchsatz = ca. 2.315 Benachrichtigungen/Sekunde.
• Reale Systeme haben Spitzen, daher Auslegung auf mindestens 10-fachen Spitzen-Headroom: 20.000 bis 30.000 Benachrichtigungserstellungen/Sekunde, wobei der Kanal-Fanout die nachgelagerte Zustellung erhöht.
• Diese Skalierung ist mit partitionierten Warteschlangen und horizontal skalierten zustandslosen Workern sehr gut zu bewältigen.

2. Datenbankschema

Verwenden Sie ein geteiltes Modell:

• Transaktionaler, dauerhafter Speicher für kanonische Benachrichtigungsdatensätze und Präferenzen
• Cache für häufige Lesevorgänge
• Optionaler Such-/Indexspeicher für erweiterte Inbox-Abfragen

Grundlegendes Schema

users_notification_preferences

• user_id PK
• push_enabled boolean
• email_enabled boolean
• in_app_enabled boolean
• quiet_hours_start
• quiet_hours_end
• timezone
• locale
• email_address
• email_verified boolean
• push_tokens json / separate Tabelle
• notification_type_settings json oder normalisierte Kindertabelle
• updated_at

user_device_tokens

• token_id PK
• user_id
• platform
• device_token
• app_version
• last_seen_at
• is_active
• unique(device_token)
• index(user_id)

notifications

• notification_id PK
• recipient_user_id
• actor_user_id nullable
• type
• object_type
• object_id
• dedupe_key
• title
• body
• payload json
• priority
• created_at
• expire_at nullable
• aggregation_key nullable
• source_event_id unique
• indexes:
  • (recipient_user_id, created_at desc)
  • (recipient_user_id, notification_id)
  • unique(source_event_id) oder unique(dedupe_key)

notification_deliveries

• delivery_id PK
• notification_id
• channel enum(push, email, in_app)
• status enum(pending, sent, delivered, failed, suppressed)
• provider_message_id nullable
• attempt_count
• last_attempt_at
• next_retry_at nullable
• failure_reason nullable
• delivered_at nullable
• indexes:
  • (notification_id)
  • (channel, status, next_retry_at)

notification_reads

• notification_id
• user_id
• read_at
• primary key(notification_id, user_id)
• index(user_id, read_at)

Optionale Optimierung: user_inbox Tabelle

• user_id
• notification_id
• created_at
• read_state
• primary key(user_id, created_at, notification_id)
  Dies kann die Haupttabelle in einem Wide-Column-Store für den Inbox-Abruf sein.

Speicherauswahl

• Präferenzen: Relationale DB oder stark konsistenter Key-Value-Store.
• Benachrichtigungen/Inbox: Cassandra/DynamoDB/Bigtable-artige Wide-Column-KV sind attraktiv, da das Zugriffsmuster hauptsächlich über user_id und zeitnahe zeitlich geordnete Lesevorgänge mit sehr hohem Schreibvolumen erfolgt.
• Zustellungsprüfung/Status: Relationaler oder KV-Speicher je nach Reporting-Anforderungen.
• Cache: Redis für ungelesene Zählungen und aktuelle Inbox-Seiten.

3. Skalierungsstrategie

Horizontale Skalierung

• Alle zustandslosen Dienste skalieren horizontal automatisch: Orchestrator, Channel Worker, Read APIs, WebSocket Gateways.
• Partitionieren Sie Ereignis-Topics nach recipient_user_id, um die Last gleichmäßig zu verteilen und die Reihenfolge pro Benutzer beizubehalten.
• Trennen Sie Warteschlangen nach Kanal und Priorität, damit ein E-Mail-Rückstand die Push-Latenz nicht beeinträchtigt.

Datenskalierung

• Shard-Benachrichtigungsdaten nach user_id.
• Verwenden Sie Zeit-Bucketing, falls für sehr große Benutzer erforderlich, z. B. Partitionsschlüssel (user_id, month).
• TTL für ältere, geringwertige Benachrichtigungen nach Ablauf der Aufbewahrungsfrist, falls geschäftlich zulässig, während die Archivierung in kostengünstigen Objektspeicher erfolgt.
• Cache für ungelesene Zählungen und die neuesten N Benachrichtigungen.

Traffic Shaping

• Prioritätsspuren:
  • hoch: direkte Erwähnungen, Nachrichten, Sicherheitswarnungen
  • mittel: Kommentare, Likes
  • niedrig: zusammenfassbare Aktivitäten oder Werbeartikel
• Schützen Sie während Spitzen die Benachrichtigungen mit hoher Priorität zuerst.
• Stapeln Sie die Generierung von E-Mails mit niedriger Priorität.

Fanout-Strategie

• Bevorzugen Sie Fanout-on-Write für benutzerspezifische Inbox- und Echtzeitkanäle, da das Latenzziel unter 2 Sekunden liegt.
• Für extrem große Fanout-Ereignisse, wie z. B. Promi-Posts an Millionen von Benutzern, verwenden Sie eine hybride Handhabung:
  • Erstellen Sie ein grobes Ereignis einmal
  • Asynchrones Fanout in Batches
  • Möglicherweise Herabstufung nicht kritischer Kanäle auf Digest oder verzögerte Zustellung
    Dies vermeidet Stampedes.

Geo-Skalierung

• Multi-Region Active-Active für Ingestion- und Delivery-APIs.
• Behalten Sie die Benutzeraffinität zur Heimatregion bei, wenn möglich, um regionsübergreifende Schreibvorgänge zu reduzieren.
• Replizieren Sie kritische Metadaten global.
• Kanalanbieter werden aus der nächstgelegenen Region aufgerufen.

Kapazitätsplanung

• 200 Mio. kanonische Benachrichtigungen/Tag.
• Wenn jede im Durchschnitt 2 bis 3 Kanalversuche erzeugt, können nachgelagerte Zustellungsdatensätze 400 Mio. bis 600 Mio./Tag betragen.
• Verwenden Sie Warteschlangenpartitionen, die für den Spitzen-Durchsatz ausgelegt sind, z. B. Dutzende bis Hunderte von Partitionen, abhängig vom Broker.
• WebSocket-Gateway, dimensioniert nach gleichzeitigen Online-Benutzern, nicht nach DAU.

4. Zuverlässigkeit und Fehlertoleranz

Verfügbarkeitsziel: 99,9%

• Multi-AZ-Bereitstellung für jede Ebene.
• Kein Single Point of Failure.
• Load Balancer über Instanzen hinweg.
• Verwalteter Broker und DB mit Replikation.

Kein Verlust von Benachrichtigungsdaten

• Speichern Sie die kanonische Benachrichtigung vor Zustellungsversuchen.
• Verwenden Sie einen dauerhaften Log/Queue mit Replikationsfaktor >= 3.
• Idempotente Konsumenten und Producer-Wiederholungen.
• Outbox-Muster für vorgelagerte Producer-Dienste, wenn diese Benachrichtigungsereignisse aus transaktionalen Operationen ausgeben.
  • Beispiel: Ein Kommentar-Schreibvorgang und ein Benachrichtigungsereignis werden mittels DB-Transaktion + Outbox verknüpft, um verlorene Ereignisse zu vermeiden.
• Replay-Fähigkeit aus dem Ereignisprotokoll und der DLQ.

Fehlerbehandlung

• Mindestens einmalige Zustellung intern, mit Deduplizierung auf Orchestrator- und Kanalebene.
• Exponentielles Backoff für Wiederholungen bei transienten Anbieterfehlern.
• DLQ für fehlerhafte oder wiederholt fehlschlagende Aufgaben.
• Circuit Breaker um APNS/FCM/E-Mail-Anbieter.
• Fallback-Verhalten:
  • Wenn der Push-Anbieter beeinträchtigt ist, speichern Sie trotzdem die In-App-Benachrichtigung
  • Wenn der E-Mail-Anbieter ausgefallen ist, halten Sie ihn in der Warteschlange und versuchen Sie es später erneut

Datenkonsistenz und -integrität

• Eindeutige source_event_id oder dedupe_key verhindert die Erstellung doppelter Benachrichtigungen.
• Der Zustellungsstatusautomat vermeidet ungültige Übergänge.
• Starke Konsistenz für Präferenzaktualisierungen, wenn eine sofortige Wirkung erforderlich ist, andernfalls begrenzte Veralterung durch Cache-Invalidierung.

Disaster Recovery

• Regionsübergreifend replizierte Metadaten und Backups.
• Periodische Snapshots plus WAL/Binlog oder Stream-Aufbewahrung.
• Definierte RPO nahe Null durch repliziertes, dauerhaftes Protokoll.
• RTO minimiert durch Infrastructure-as-Code und Warm-Standby/Active-Active-Design.

Betriebliche Zuverlässigkeit

• SLOs für Latenz von der Einreihung bis zur Speicherung und von der Speicherung bis zur Zustellung.
• Alarme für Warteschlangenverzögerung.
• Synthetische Sonden für Push-/E-Mail-/In-App-Pfade.
• Backpressure-Kontrollen, wenn nachgelagerte Anbieter drosseln.
• Ratenbegrenzungen pro Mandant/Ereignistyp zur Eindämmung von Missbrauch.

5. Wichtige Kompromisse

Kompromiss 1: Mindestens einmalige Zustellung vs. genau einmalige Zustellung

• Gewählt: Mindestens einmal mit Idempotenz.
• Warum: Genau einmal über Broker, Datenbanken und externe Anbieter wie APNS/FCM/E-Mail ist teuer und oft unpraktisch.
• Auswirkung: Gelegentliche doppelte Versuche sind möglich, aber Deduplizierungsschlüssel und idempotente Schreibvorgänge machen für den Benutzer sichtbare Duplikate selten.
• Vorteil: Viel einfacher und zuverlässiger bei Ausfällen.

Kompromiss 2: Wide-Column/KV-Speicher vs. relationale DB für Benachrichtigungs-Inbox

• Gewählt: Wide-Column- oder Dynamo-ähnlicher Speicher für Inbox, relational für Präferenzen und einige Metadaten.
• Warum: Die Benachrichtigungs-Workload ist schreibintensiv, append-lastig und liest hauptsächlich nach Benutzer und Aktualität.
• Auswirkung: Schwächere Ad-hoc-Abfragefähigkeiten und sorgfältigere Datenmodellierung.
• Vorteil: Weitaus bessere horizontale Skalierung und vorhersehbare Leistung.

Kompromiss 3: Fanout-on-Write vs. Fanout-on-Read

• Gewählt: Größtenteils Fanout-on-Write.
• Warum: Latenzanforderung unter 2 Sekunden und Bedarf an sofortiger Push-/In-App-Zustellung.
• Auswirkung: Mehr Schreibverstärkung, insbesondere bei Ereignissen mit hohem Fanout.
• Abhilfe: Hybrider Ansatz für Mega-Fanout-Fälle.

Kompromiss 4: Echtzeit-Push-Zustellung vs. reiner Pull-Inbox

• Gewählt: Hybrid.
• Warum: Push/WebSocket bietet geringe Latenz für aktive Benutzer, die Pull-API bietet Ausfallsicherheit für Offline-Benutzer.
• Auswirkung: Mehr Systemkomplexität, da sowohl der Verbindungsstatus als auch die Inbox-Persistenz erforderlich sind.
• Vorteil: Beste Benutzererfahrung und Zuverlässigkeit.

Zusammenfassung der vorgeschlagenen endgültigen Architektur

• Erfassung von Ereignissen über einen dauerhaften Event Bus.
• Verwendung eines zustandslosen Notification Orchestrators zum Deduplizieren, Prüfen von Präferenzen, Speichern von Benachrichtigungsdatensätzen und Veröffentlichen von kanal-spezifischen Aufträgen.
• Speicherung von Inbox-Daten in einem horizontal skalierbaren, benutzer-partitionierten Speicher, mit relationalen oder stark konsistenten KV für Präferenzen.
• Zustellung über dedizierte Push-, E-Mail- und In-App-Worker.
• Verwendung von WebSocket/SSE für Echtzeit-In-App-Updates und normale Read-APIs für den Inbox-Abruf.
• Gewährleistung der Zuverlässigkeit durch Multi-AZ-Bereitstellung, replizierte Warteschlangen, dauerhafte Erstschreibvorgänge, Idempotenz, Wiederholungsversuche, DLQs, Replay und regionsübergreifendes Disaster Recovery.

Dieses Design unterstützt problemlos 10 Mio. DAU und 200 Mio. Benachrichtigungen/Tag und erfüllt dabei die Zustellung von Echtzeit-Benachrichtigungen in unter 2 Sekunden und hält eine Verfügbarkeit von 99,9 % ohne Datenverlust aufrecht.