Entwurf eines Echtzeit-Benachrichtigungsdienstes

Real-Time Notification Service — High-Level System Design ================================================================================ 0. BACK-OF-THE-ENVELOPE ESTIMATION ================================================================================ - 10M DAU × 20 notifications/user/day = 200M notifications/day - 200M / 86,400s ≈ 2,315 notifications/second (average) - Peak load (assume 5× average) ≈ 11,575 notifications/second - Each notification payload ~1 KB → ~200 GB/day raw data ingestion - Latency budget: < 2 seconds end-to-end (ingestion → delivery to device) ================================================================================ 1. CORE ARCHITECTURE ================================================================================ The system follows an event-driven, microservices architecture with the following key components: ┌──────────────┐ │ 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) │ └────────────────┘ Component Descriptions: A) API Gateway / Load Balancer - Entry point for internal producer services and external API calls (e.g., mark-as-read). - Handles rate limiting, authentication, and request routing. - Distributes traffic across multiple Notification Service instances. B) Notification Service (NS) - Stateless microservice deployed in multiple replicas behind the load balancer. - Receives notification events, validates them, performs deduplication (idempotency key check). - Looks up user notification preferences from a cache (Redis) or database. - Determines which channels to deliver on (push, email, in-app) based on preferences. - Persists the notification record to the database. - Publishes channel-specific messages to Kafka topics. C) Message Queue (Apache Kafka) - Decouples notification creation from delivery, absorbing traffic spikes. - Partitioned by user_id hash to preserve per-user ordering. - Provides durability (replication factor = 3) and replay capability. - Separate topics per channel allow independent scaling of consumers. D) Channel Workers (Consumer Groups) - Push Worker Pool: Consumes from push_notifications topic, batches requests, and sends to APNs (iOS) and FCM (Android). Handles token management and retry logic. - Email Worker Pool: Consumes from email_notifications topic, renders templates, and sends via SES/SendGrid. Implements exponential backoff for transient failures. - In-App Worker Pool: Consumes from in_app_notifications topic, pushes to WebSocket Gateway for real-time delivery. Falls back to polling if WebSocket is disconnected. E) WebSocket Gateway - Maintains persistent WebSocket connections with online users. - Horizontally scaled; uses Redis Pub/Sub or a shared message bus so any gateway node can deliver to any connected user. - Connection registry stored in Redis (user_id → gateway_node mapping). F) Notification Read API - Separate read path for fetching notification history, marking as read, managing preferences. - Served from read replicas / cache to avoid impacting the write path. ================================================================================ 2. DATABASE SCHEMA ================================================================================ Primary data store: PostgreSQL (for preferences and metadata) + Cassandra (for notification storage at scale). --- PostgreSQL (User Preferences & Metadata) --- 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' -- Per-category overrides 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 (Notification Storage — optimized for time-series reads) --- TABLE: notifications user_id UUID -- Partition key created_at TIMEUUID -- Clustering key (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 for extensibility PRIMARY KEY ((user_id), created_at) WITH CLUSTERING ORDER BY (created_at DESC) AND default_time_to_live = 7776000 -- 90-day TTL TABLE: notification_counts (materialized/counter table) user_id UUID PRIMARY KEY unread_count COUNTER --- Redis (Caching Layer) --- - User preferences cache: Key = pref:{user_id}, TTL = 10 min - Unread count cache: Key = unread:{user_id}, TTL = 5 min - Deduplication set: Key = dedup:{idempotency_key}, TTL = 24 hours - WebSocket connection registry: Key = ws:{user_id} → gateway_node_id ================================================================================ 3. SCALING STRATEGY ================================================================================ A) Horizontal Scaling of Stateless Services - Notification Service, all Worker Pools, and WebSocket Gateway are stateless and horizontally scalable. - Auto-scaling groups (Kubernetes HPA) based on CPU, memory, and queue lag metrics. - Target: each NS instance handles ~500 req/s; need ~25 instances at peak. B) Kafka Partitioning - Start with 64 partitions per topic (allows up to 64 consumers per group). - Partition by user_id hash for ordering guarantees per user. - Scale partitions as throughput grows (re-partition with care). - Separate consumer groups per channel allow independent scaling. C) Database Scaling - Cassandra: Naturally horizontally scalable. Start with a 6-node cluster (RF=3). Add nodes as data volume grows. Partition key = user_id distributes load evenly. - PostgreSQL: Vertical scaling initially for preferences (relatively small dataset: 10M rows). Add read replicas for read-heavy preference lookups. Consider sharding by user_id if needed. - Redis Cluster: 3+ nodes with automatic sharding for cache and connection registry. D) WebSocket Gateway Scaling - Each gateway node handles ~100K concurrent connections. - 10M DAU with ~30% concurrent online = 3M connections → ~30 gateway nodes. - Redis Pub/Sub or a lightweight message bus (e.g., NATS) for cross-node message routing. - Consistent hashing for user-to-node assignment with graceful rebalancing. E) Rate Limiting and Backpressure - Rate limit notification producers to prevent abuse (e.g., max 1000 events/sec per producer). - Kafka consumer lag monitoring with alerts; auto-scale consumers when lag exceeds threshold. - Circuit breakers on external services (APNs, FCM, SES) to prevent cascade failures. F) Future Growth Path - Move to a multi-region deployment with Kafka MirrorMaker 2 for cross-region replication. - Introduce a notification aggregation/batching layer (e.g., "X and 5 others liked your post"). - Add a priority queue for time-sensitive notifications (e.g., direct messages vs. like notifications). ================================================================================ 4. RELIABILITY AND FAULT TOLERANCE ================================================================================ A) Data Durability - Kafka: Replication factor = 3, min.insync.replicas = 2, acks = all. Guarantees no data loss even if one broker fails. - Cassandra: Replication factor = 3, write consistency = QUORUM (2 of 3). Tolerates single-node failure without data loss. - PostgreSQL: Synchronous replication to at least one standby. B) At-Least-Once Delivery - Kafka consumers commit offsets only after successful processing. - Workers implement idempotent delivery using notification_id as dedup key. - If a push/email delivery fails, the message stays in Kafka for retry. - Dead Letter Queue (DLQ) for messages that fail after N retries (e.g., 5 retries with exponential backoff). C) High Availability (99.9% target = max 8.76 hours downtime/year) - All services deployed across 3 Availability Zones (AZs). - Kubernetes with pod anti-affinity rules ensures replicas are spread across AZs. - Database clusters span multiple AZs with automatic failover. - Load balancer health checks with automatic removal of unhealthy instances. - Blue-green or canary deployments to minimize deployment-related downtime. D) Graceful Degradation - If push notification service (APNs/FCM) is down, notifications are queued in Kafka and retried. - If WebSocket gateway is overloaded, clients fall back to polling the notification read API. - If Cassandra is temporarily unavailable, notifications are buffered in Kafka (which has multi-day retention). - Circuit breaker pattern on all external dependencies with fallback behavior. E) Monitoring and Alerting - End-to-end latency tracking: timestamp at creation → timestamp at delivery (P50, P95, P99). - Kafka consumer lag monitoring per topic and consumer group. - Error rate dashboards per channel (push failure rate, email bounce rate). - Alerting on: latency > 2s at P95, consumer lag > 10K messages, error rate > 1%, availability < 99.9%. F) Disaster Recovery - Kafka topic data retained for 7 days, allowing replay from any point. - Cassandra snapshots taken daily, stored in S3 with cross-region replication. - PostgreSQL WAL archiving to S3 for point-in-time recovery. - Runbook for full cluster recovery with target RTO < 1 hour, RPO < 5 minutes. ================================================================================ 5. KEY TRADE-OFFS ================================================================================ Trade-off 1: Availability vs. Strict Consistency (AP over CP) Decision: We chose eventual consistency for notification delivery and read status. - Cassandra with QUORUM writes provides strong-enough consistency for notifications while prioritizing availability and partition tolerance. - A user might briefly see a stale unread count (cached in Redis with 5-min TTL), but this is acceptable for a notification system where perfect real-time accuracy of counts is not critical. - The alternative — using a strongly consistent database like PostgreSQL for all notification storage — would create a scaling bottleneck at 200M writes/day and risk availability during network partitions. - Impact: Users may occasionally see a notification count that is off by 1-2 for a few seconds. This is a minor UX issue compared to the risk of the entire notification system becoming unavailable. Trade-off 2: Push Model (WebSockets) vs. Pull Model (Polling) for In-App Notifications Decision: We chose a push-first model using WebSockets with polling as a fallback. - Push via WebSockets delivers notifications in real-time (sub-second) meeting our <2s latency requirement. - However, maintaining millions of persistent connections is resource-intensive (~30 gateway nodes for 3M concurrent connections) and adds operational complexity (connection management, heartbeats, reconnection logic). - The alternative — pure polling — would be simpler to operate but would either increase latency (if polling interval is long) or increase server load dramatically (if polling interval is short). At 3M concurrent users polling every 2 seconds = 1.5M req/s just for polling, which is far more expensive than maintaining WebSocket connections. - Compromise: We use WebSockets for online users and fall back to polling (with longer intervals) when WebSocket connections cannot be established (e.g., restrictive firewalls). Push notifications via APNs/FCM handle the case when the user is offline. Trade-off 3: Single Notification Store (Cassandra) vs. Polyglot Persistence Decision: We use Cassandra for notification storage and PostgreSQL for user preferences/metadata rather than a single database for everything. - Cassandra excels at high-throughput time-series writes (200M/day) and partition-key-based reads (fetch notifications for a user), which is the dominant access pattern. - PostgreSQL is better suited for the relational nature of user preferences (joins with user table, transactional updates to preferences). - The trade-off is increased operational complexity (two database systems to maintain, monitor, and back up) and the need to keep data consistent across systems (e.g., if a user is deleted, notifications must be cleaned up in Cassandra). - We mitigate this with an event-driven cleanup process: user deletion events trigger async Cassandra cleanup jobs. Trade-off 4: At-Least-Once vs. Exactly-Once Delivery Decision: We chose at-least-once delivery semantics with application-level deduplication. - Exactly-once delivery across distributed systems is extremely expensive and complex (requires distributed transactions or Kafka's exactly-once semantics with significant performance overhead). - At-least-once is simpler and more performant. Duplicate notifications are handled at the application layer using idempotency keys (notification_id checked before delivery). - The risk is that in rare failure scenarios, a user might receive a duplicate push notification. This is a minor annoyance compared to the alternative of lost notifications (at-most-once) or the complexity/performance cost of exactly-once. ================================================================================ SUMMARY ================================================================================ This design handles 200M notifications/day across three channels with sub-2-second delivery latency. The event-driven architecture with Kafka as the central nervous system provides durability, decoupling, and natural backpressure handling. Cassandra provides horizontally scalable notification storage, while the WebSocket gateway enables real-time in-app delivery. The system is designed for 99.9% availability through multi-AZ deployment, replication at every layer, and graceful degradation patterns. The key trade-offs favor availability, scalability, and operational simplicity over strict consistency and exactly-once semantics, which are appropriate choices for a notification system where occasional staleness or rare duplicates are acceptable.

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.