Entwerfen Sie ein Echtzeit-Benachrichtigungssystem für E-Commerce

Übersicht Ich schlage eine horizontal skalierbare, Streaming-first-Benachrichtigungsplattform vor, die aus entkoppelten Microservices und verwalteten Cloud-Diensten aufgebaut ist. Kernideen: Verwendung eines dauerhaften Ereignisprotokolls für die Aufnahme und Wiedergabe (Kafka/Kinesis/Pub/Sub), Stream-Prozessoren zur Anreicherung und Personalisierung von Ereignissen, eine Zustellpipeline, die den Zustellstatus speichert und Wiederholungsversuche für "mindestens einmal"-Garantien durchführt, sowie gerätespezifische Konnektoren für Push (APNs/FCM) und Echtzeit-Web (WebSocket). Das Design erfüllt Spitzen von 100.000 Benachrichtigungen/Minute (ca. 1.700/Sekunde), zielt auf eine Zustellung von unter 5 Sekunden für 99 % der Nachrichten ab und unterstützt Personalisierung und zuverlässige Zustellung. Hochrangige Architektur (Komponenten und Interaktionen) 1) Ereignisproduzenten - Quellen: Bestellservice (Bestellaktualisierungen), Preisgestaltungsservice (Preisänderungen), Marketing/CRM (Flash Sales). Jeder Dienst gibt bei jeder relevanten Änderung leichte Ereignisse an die Erfassungsschicht aus. Ereignisse umfassen event_id, event_type, payload, timestamp und Metadaten (user_ids oder product_ids). 2) Erfassung / Dauerhaftes Ereignisprotokoll - Verwaltetes partitioniertes Protokoll: Apache Kafka (selbstverwaltet oder Confluent Cloud) oder Cloud-Äquivalente (AWS Kinesis Data Streams, GCP Pub/Sub). Produzenten veröffentlichen Ereignisse in Topic(s), die nach Ereignistyp und Partitionsschlüssel (user_id oder product_id) organisiert sind, um die Reihenfolge zu wahren, wo dies erforderlich ist (z. B. Bestellaktualisierungen pro Bestellung). - Warum dauerhaftes Protokoll: Bietet Wiedergabefähigkeit, Aufbewahrung für Wiederholungsversuche und Glättung von Rückstau. 3) Stream-Verarbeitung / Anreicherungsschicht - Zustandslose/zustandsbehaftete Stream-Prozessoren (Apache Flink, Kafka Streams oder verwaltetes Dataflow) abonnieren Ereignis-Topics, um: Ereignisse zu validieren, mit Benutzerprofilen und Präferenzen anzureichern, mit Produkt-/Segmentdaten zu verknüpfen und die Berechtigung und Priorität von Benachrichtigungen zu entscheiden (z. B. kritische Bestellaktualisierung vs. Marketing). - Ausgabe: normalisierte Benachrichtigungsaufgaben (task_id, user_id(s), payload, type, priority, ttl, dedup_key), die in einem Benachrichtigungsaufgaben-Topic veröffentlicht werden. 4) Personalisierung & Segmentierung - Personalisierungsregeln leben in einem Dienst, der kombiniert: Feature Store / Profil-DB (DynamoDB/Cassandra/Postgres + Redis-Cache für heiße Lesevorgänge) und eine Regel-Engine oder ein ML-Modell. Stream-Prozessoren rufen diesen Dienst auf oder verwenden lokale Cache-Lookups, um gezielte Empfänger und Inhaltsvarianten zu bestimmen. - Für breite Segmentierungsereignisse (Flash Sale für ein Segment) verwenden Sie vorab berechnete Segmente, die in einem schnellen Speicher (Redis, Druid oder BigQuery/ElastiCache-Lookup) gespeichert sind, um sie in Benutzerlisten zu erweitern oder Filterlogik innerhalb von Streaming-Jobs anzuwenden. 5) Zustellungs-Orchestrierung / Fan-out - Ein Zustellungs-Orchestrierungsdienst abonniert das Benachrichtigungsaufgaben-Topic, wertet Geräte-Registrierungen, Drosselungsregeln und die Fan-out-Strategie aus. Für Benachrichtigungen an einzelne Benutzer (Bestellaktualisierung) erstellt er einen Zustellungsauftrag pro Gerät; für segmentbasierte Übertragungen wird er über eine partitionierte Warteschlange in viele Zustellungsaufträge aufgeteilt. - Zustellungsaufträge werden in dauerhafte, pro-Shard-Zustellungswarteschlangen (Kafka-Topics, Redis Streams oder SQS mit FIFO für die Reihenfolge, wo nötig) eingestellt. Aufträge enthalten Wiederholungszähler und Idempotenz-/Deduplizierungsschlüssel. 6) Zustellungs-Worker / Konnektoren - Zustandslose Worker-Flotte, die durch Warteschlangenverzögerung skaliert wird. Jeder Worker zieht Aufträge, versucht die Zustellung über den für den Gerätekanal geeigneten Konnektor: - Mobile Push: FCM (Android) und APNs (iOS) unter Verwendung von Gerätetoken, die in der Geräte-Registrierung gespeichert sind. - Web/Browser: Web Push (VAPID) oder persistente WebSocket-Verbindungen (verwaltet über einen Verbindungsservice wie AWS API Gateway WebSocket oder selbstverwaltete Socket-Cluster hinter ELB). - Fallback-Kanäle: E-Mail (SES/SendGrid) oder SMS (Twilio) für kritische, nicht zugestellte Benachrichtigungen. - Worker speichern Zustellversuche (Erfolg/Fehler) in einem Zustellstatus-Speicher und geben Abschluss- oder Wiederholungsereignisse an das Protokoll zur Überwachung und für weitere Wiederholungsversuche aus. 7) Geräte-Registrierung & Benutzereinstellungen - Dauerhafter Speicher von user_id -> Geräten (Token, Plattform, zuletzt gesehen, Einstellungen, Opt-in-Flags). Verwenden Sie DynamoDB/Cassandra für hohen Schreibdurchsatz; cachen Sie aktive Geräte in Redis für Lesezugriffe mit geringer Latenz. 8) Zustellungsstatus & Wiedergabefähigkeit - Alle Benachrichtigungsaufgaben und Zustellversuche werden in dauerhaften Speichern (Kafka + Archivierung nach S3) und einer Zustellstatus-DB protokolliert. Dies ermöglicht eine "mindestens einmal"-Zustellung, Überprüfung und Abgleich. Nicht bestätigte/fehlgeschlagene Zustellungen werden von einem Wiederholungs-Orchestrator mit exponentiellem Backoff wiederholt. 9) Überwachung, Beobachtbarkeit und SLA-Durchsetzung - Metriken: Erfassungsrate, Verarbeitungsverzögerung, Warteschlangenverzögerung, Zustellungserfolgsrate. Traces für Pfad-Latenz (OpenTelemetry) und Alarme für SLA-Verletzungen. Dashboards zur Überwachung der 99p-Latenz und der Fehlerraten pro Kanal. Wichtige Designentscheidungen und Begründungen - Dauerhaftes Protokoll (Kafka/Kinesis/PubSub): Bietet hohen Durchsatz und Wiedergabefähigkeit, was für "mindestens einmal"-Semantik und Debugging unerlässlich ist. Partitionierung nach user_id/product_id wahrt die Reihenfolge pro Entität (entscheidend für Bestellaktualisierungen). Verwaltetes Cloud-Streaming reduziert den Betriebsaufwand. - Stream-Verarbeitung (Flink/Kafka Streams/Dataflow): Ermöglicht Anreicherung und Segmentierung mit Sub-Sekunden-Latenz nahe der Erfassung. Zustandsbehaftetes Streaming unterstützt Fenster-Joins (z. B. Abgleich von Preisdrop-Ereignissen mit Wunschlisten) mit geringer Latenz. - Geräte-Registrierung in NoSQL + Cache: DynamoDB/Cassandra skaliert horizontal für zig Millionen Benutzer; Redis verarbeitet Hot-Path-Lookups für Entscheidungen mit geringer Latenz. - Zustellungswarteschlangen und skalierte Worker: Entkoppelt den schweren Fan-out von der vorgelagerten Verarbeitung, ermöglicht eine reibungslose Skalierung während Flash Sales und kontrolliert gleichzeitig die Ratenbegrenzungen des nachgelagerten Push-Anbieters. - Push-Konnektoren (APNs/FCM) + WebSockets: Push-Dienste minimieren das Client-Polling und erreichen geringe Latenz. WebSockets werden für die Echtzeit-Zustellung in Apps/Webs verwendet; wenn WebSocket nicht verfügbar ist, wird auf Push oder Pull zurückgegriffen. - Mindestens einmal, Idempotenz und Deduplizierung: Speichern Sie task-level dedup_key und machen Sie die Zustellung auf dem Client idempotent oder verwenden Sie SDK-Bestätigungen, wo immer möglich. Serverseitig deduplizieren Sie nach task_id/dedup_key, bevor Sie für den Benutzer sichtbare Benachrichtigungen erstellen. Erfüllung der Anforderungen - Hoher Durchsatz: Partitionierte Protokolle und skalierte Worker unterstützen horizontale Skalierung; Kafka/Kinesis können Millionen von Ereignissen/Sekunde mit mehreren Partitionen verarbeiten. 100.000/Minute sind für solche Systeme bescheiden; die Architektur kann durch Hinzufügen von Partitionen und Workern auf viel höhere Volumina skaliert werden. - Geringe Latenz: Streaming-Anreicherung und direkte Push/WebSocket-Konnektoren sind Pfade mit geringer Latenz. Ziel <5s 99p: Halten Sie die Verarbeitungspipeline unter 1–2s (Streaming-Jobs), geringe Verzögerung der Zustellungswarteschlange durch skalierte Worker und verwenden Sie Geräte-Caches, um DB-Lookups im Hot Path zu vermeiden. - Zuverlässigkeit: Dauerhaftes Ereignisprotokoll + gespeicherte Zustellstatus + Wiederholungs-Orchestrator gewährleisten eine "mindestens einmal"-Zustellung. Für kritische Benachrichtigungen (Bestellaktualisierungen) aktivieren Sie stärkere Garantien: synchrone Bestätigung von nachgelagerten Diensten und Speicherung eines bestätigten Zustellungsbelegs (z. B. Geräte-Ack oder Bestätigung des Fallback-Kanals). Verwenden Sie exponentielles Backoff und Eskalation zu alternativen Kanälen. - Skalierbarkeit: Alle zustandsbehafteten Teile verwenden horizontal skalierbare Speicher (Kafka, DynamoDB/Cassandra, Redis-Cluster). Worker und Streamer sind zustandslose Container, die automatisch skalieren. Verwenden Sie Partitionierung und Sharding für Wachstum. - Personalisierung: Echtzeit-Joins in Stream-Prozessoren plus gespeicherter Profilspeicher ermöglichen eine pro-Benutzer-Personalisierung. Vorab berechnete Segmente beschleunigen große Fan-outs (Flash Sales), indem sie die Auswertung pro Benutzer on the fly vermeiden. Kompromisse (Konsistenz, Verfügbarkeit, Kosten) - Konsistenz vs. Verfügbarkeit: Wir bevorzugen Verfügbarkeit und eventual consistency für Marketing-Benachrichtigungen (akzeptabel, wenn eine Aktion leicht außer Reihenfolge ankommt). Für Bestell-kritische Ereignisse verwenden wir stärkere Reihenfolge und Persistenz (Partitionierung und synchrone Persistenz), um korrekte Reihenfolge und zuverlässige Zustellung zu gewährleisten. Dieser hybride Ansatz gleicht Benutzererfahrung und Systemresilienz aus. - Mindestens einmal vs. Genau einmal: Das Erreichen von "genau einmal" in der gesamten Pipeline verursacht Komplexität und Kosten (transaktionales Kafka, Two-Phase Commit oder End-to-End-Idempotenz). Wir wählen "mindestens einmal" mit idempotentem Handler und Deduplizierungsschlüsseln, um doppelt sichtbare Benachrichtigungen zu vermeiden und gleichzeitig das System einfacher und skalierbarer zu halten. - Verwaltete Dienste vs. selbst gehostet: Verwaltetes Streaming (Kinesis/PubSub) und Push-Infrastruktur reduzieren den Betriebsaufwand und erhöhen die Verfügbarkeit, sind aber teurer. Für Geschwindigkeit bei der Markteinführung und Zuverlässigkeit im großen Maßstab werden verwaltete Dienste empfohlen. Wenn die Kosten dominieren, erwägen Sie selbst gehostetes Kafka mit starker Automatisierung. Betriebliche Überlegungen - Ratenbegrenzung / Drosselung: Kontingente pro Benutzer und pro Anbieter, um Überlastung und Ablehnungen von Anbieter-Ratenbegrenzungen zu vermeiden. - Backfill und Wiedergabe: Verwenden Sie das dauerhafte Protokoll, um verpasste Benachrichtigungen (z. B. nach einem Ausfall) erneut zu senden und den Zustellstatus wiederherzustellen. - Tests: Chaos-Tests für Partitionen und Anbieter-Ausfälle, Lasttests zur Validierung der 99p-Latenz unter Spitzenlast. - Sicherheit & Datenschutz: Token im Ruhezustand verschlüsseln, Push-Anmeldeinformationen rotieren, Opt-outs und PII-Kontrollen berücksichtigen. SLA und zu überwachende KPIs - Durchsatz (Ereignisse/Minute), Stream-Verarbeitungsverzögerung (p50/p90/p99), Ende-zu-Ende-Zustellungsverzögerung (p50/p90/p99), Zustellungserfolgsrate pro Kanal, Wiederholungsrate, Warteschlangenverzögerung und Consumer-Gruppenverzögerung. Zusammenfassung Dieses Design verwendet ein dauerhaftes, partitioniertes Ereignisprotokoll plus Stream-Verarbeitung für Anreicherung/Personalisierung, eine persistente Zustellpipeline mit automatisch skalierten Workern für Fan-out und kanalspezifische Konnektoren (APNs/FCM/WebSocket) für schnelle Zustellung. Es priorisiert Verfügbarkeit und Wiedergabefähigkeit, um eine "mindestens einmal"-Zustellung zu erreichen, nutzt Caching und Partitionierung, um geringe Latenz und hohen Durchsatz zu erzielen, und stützt sich auf verwaltete Cloud-Komponenten, um den Betriebsaufwand zu reduzieren und gleichzeitig die horizontale Skalierung zur Unterstützung zukünftigen Wachstums zu ermöglichen.

Entwurf eines Echtzeit-Benachrichtigungssystems für E-Commerce Übersicht Das vorgeschlagene System ist eine ereignisgesteuerte, Microservices-basierte Architektur, die Ereignisse von mehreren vorgelagerten Diensten aufnimmt, sie über einen Message Broker verarbeitet und weiterleitet und Benachrichtigungen mit mindestens einmaliger Zustellungsgarantie, Latenzzeiten von unter 5 Sekunden in der 99. Perzentile und der Fähigkeit, Spitzenereignisse mit 100.000 Benachrichtigungen pro Minute zu bewältigen, an 50 Millionen Benutzer über mobile und Webkanäle liefert. Das Design geht von einer Cloud-nativen Bereitstellung auf AWS aus, obwohl die Prinzipien direkt auf GCP- oder Azure-Äquivalente übertragbar sind. Architektur auf hoher Ebene Die Architektur besteht aus sechs logischen Ebenen: Event Producers, Event Ingestion, Processing and Routing, User Preference and Segmentation, Delivery und Observability. 1. Event Producers Mehrere vorgelagerte Dienste generieren Ereignisse, die Benachrichtigungen auslösen. Dazu gehören der Order Service (der Ereignisse wie order-placed, shipped, out-for-delivery, delivered ausgibt), der Pricing Service (der price-drop-Ereignisse ausgibt, wenn der Preis eines beobachteten Artikels unter einen Schwellenwert fällt) und der Campaign Service (der flash-sale-start-Ereignisse ausgibt, die vom Marketingteam erstellt wurden). Jeder Producer veröffentlicht eine strukturierte Event-Envelope mit einem Ereignistyp, einem Zeitstempel, einer Nutzlast und einem Idempotenzschlüssel an eine zentrale Ingestion-Schicht. Producer verwenden einen asynchronen Fire-and-Forget-Publish-Aufruf, sodass ihre eigene Latenz nicht beeinträchtigt wird. 2. Event Ingestion Layer — Apache Kafka Alle Ereignisse fließen in Apache Kafka (Amazon MSK in AWS). Kafka wird aus mehreren Gründen gewählt. Erstens bietet es dauerhafte, nur angehängte Protokolle mit konfigurierbarer Replikation (Replikationsfaktor 3, min.insync.replicas 2), was bedeutet, dass ein bestätigter Schreibvorgang den Verlust eines einzelnen Brokers überlebt und somit die Zuverlässigkeitsanforderung direkt unterstützt. Zweitens ermöglicht das partitionierte Topic-Modell von Kafka die horizontale Skalierung: Wir partitionieren das order-events-Topic nach Benutzer-ID, sodass alle Ereignisse für einen bestimmten Benutzer in der richtigen Reihenfolge verarbeitet werden, während das gesamte Topic über Dutzende von Partitionen verteilt werden kann, um den Spitzen-Durchsatz aufzunehmen. Bei 100.000 Benachrichtigungen pro Minute beträgt die durchschnittliche Rate etwa 1.667 Ereignisse pro Sekunde, was gut innerhalb der Kapazität eines bescheidenen Kafka-Clusters liegt, aber die Partitionierung ermöglicht uns, ohne architektonische Änderungen auf das 10-fache oder mehr zu skalieren. Drittens entkoppelt Kafka Producer von Consumern, sodass eine vorübergehende Verlangsamung in der Delivery-Schicht den Order Service nicht rückwärts belastet. Topic-Design: Separate Topics für order-events, price-events und campaign-events. Dies ermöglicht unabhängige Consumer-Gruppen mit unterschiedlichen Skalierungs- und Wiederholungsrichtlinien. Abgewogener Kompromiss: Wir haben Amazon SQS plus SNS als einfachere verwaltete Alternative evaluiert. SQS würde die mindestens einmalige Zustellung erfüllen und ist betrieblich leichter, aber es fehlen die Ordnungsgarantien von Kafka pro Partition und seine Wiederholungsfähigkeit, die für die Neubearbeitung nach einem Fehler wertvoll ist. Die zusätzlichen Betriebskosten von Kafka werden durch die Vorteile der Ordnung und Wiederholung in unserem Maßstab gerechtfertigt. 3. Processing and Routing Layer — Notification Service Ein horizontal skalierter Microservice, der Notification Service, konsumiert aus Kafka-Topics. Er führt mehrere Aufgaben aus. Erstens ermittelt er die Zielgruppe. Bei Order-Ereignissen ist das Ziel ein einzelner Benutzer (aus der Nutzlast extrahiert). Bei Price-Drop-Ereignissen fragt er den Wishlist Service oder eine vorab berechnete materialisierte Ansicht ab, um alle Benutzer zu finden, die diesen Artikel beobachten. Bei Flash-Sale-Ereignissen fragt er den Segmentation Service ab, um ein Benutzersegment zu ermitteln. Zweitens reichert er die Benachrichtigung an, indem er den Anzeigenamen des Benutzers, die Produktbild-URL und die lokalisierte Nachrichten-Vorlage aus einem Template Service abruft, der von einem Redis-Cache über einer PostgreSQL-Datenbank gesichert wird. Drittens wendet er Benutzereinstellungen an. Jeder Benutzer hat ein Einstellungsdokument (gespeichert in DynamoDB für Lesezugriffe mit geringer Latenz auf Schlüssel-Wert-Paare), das die aktivierten Kanäle (Push, E-Mail, SMS, In-App), Ruhezeiten und Interessenkategorien angibt. Der Dienst filtert und berücksichtigt diese Einstellungen, was die Personalisierungsanforderung direkt unterstützt. Viertens verteilt er Zustellungsaufgaben. Für jedes ermittelte Benutzer-Kanal-Paar gibt der Dienst eine Zustellungsnachricht an ein Kafka-Topic pro Kanal aus (push-delivery, email-delivery, sms-delivery, in-app-delivery). Dieser Fan-out-Schritt ist entscheidend: Er wandelt ein logisches Ereignis in potenziell Millionen von einzelnen Zustellungsaufgaben um (für einen Flash-Sale, der sich an alle Benutzer richtet), und Kafka absorbiert diesen Burst. Skalierung: Der Notification Service läuft als Kubernetes Deployment (Amazon EKS) mit einem Horizontal Pod Autoscaler, der auf den Kafka-Consumer-Lag reagiert. Während eines Flash-Sales steigt der Consumer-Lag an, und zusätzliche Pods werden innerhalb von Sekunden hochgefahren. Idempotenz: Jede Zustellungsnachricht trägt den Idempotenzschlüssel des ursprünglichen Ereignisses in Kombination mit der Benutzer-ID. Downstream-Zustellungsworker verwenden diesen zusammengesetzten Schlüssel zur Deduplizierung, um sicherzustellen, dass Benutzer keine doppelten Benachrichtigungen erhalten, obwohl Kafka mindestens einmalige Semantiken bietet. 4. User Preference and Segmentation Benutzereinstellungen werden in Amazon DynamoDB gespeichert, partitioniert nach Benutzer-ID. DynamoDB wird wegen seiner Lese-Latenz im einstelligen Millisekundenbereich und seiner nahtlosen horizontalen Skalierbarkeit gewählt, was wichtig ist, da jede einzelne Benachrichtigung eine Abfrage der Einstellungen erfordert. Ein DAX (Dynamo-DB Accelerator)-Cache sitzt davor für häufig abgerufene Schlüssel. Für die Segmentierung (Zielgruppenansprache von Benutzern, die an einer Kategorie interessiert sind, oder Benutzer in einer geografischen Region) pflegen wir vorab berechnete Segmentmitgliedschaftslisten. Ein nächtlicher Batch-Job (Apache Spark auf EMR) und ein Echtzeit-Stream-Prozessor (Kafka Streams oder Flink) halten diese Listen in einer separaten DynamoDB-Tabelle, die nach Segment-ID indiziert ist, mit der Benutzer-ID-Liste als Wert, die für sehr große Segmente in S3 gespeichert ist. Wenn der Campaign Service einen Flash-Sale erstellt, der auf das Elektroniksegment abzielt, liest der Notification Service die Segmentmitgliedschaft und iteriert durch sie, wobei er Zustellungsaufgaben in Batches erstellt. Abwägung: Die Vorab-Berechnung von Segmenten tauscht Speicherplatz und Aktualität (ein Benutzer, der seine Einstellungen vor einer Stunde geändert hat, könnte immer noch im alten Segment sein) gegen Abfragegeschwindigkeit. Die Echtzeit-Segmentbewertung zum Zeitpunkt der Zustellung wäre genauer, würde aber das Scannen von Millionen von Benutzerdatensätzen unter Zeitdruck erfordern, was die Latenzanforderung verletzen würde. Der hybride Ansatz (nächtlicher Batch plus Echtzeit-Stream-Updates) hält die Segmente innerhalb von Minuten aktuell. 5. Delivery Layer Separate Consumer-Gruppen kümmern sich um jeden Kanal. Push-Benachrichtigungen (Mobil): Worker konsumieren aus dem push-delivery-Topic und rufen Firebase Cloud Messaging (FCM) für Android und Apple Push Notification Service (APNs) für iOS auf. Wir verwenden FCM als einheitliches Gateway für beide Plattformen, wo immer möglich. Worker bündeln Anfragen an die HTTP v1 API von FCM (bis zu 500 Nachrichten pro Batch-Aufruf), um den Durchsatz zu maximieren. Fehlgeschlagene Zustellungen (ungültige Token, Ratenbegrenzungen) werden mit exponentiellem Backoff wiederholt. Permanent fehlgeschlagene Token (nicht registrierte Geräte) lösen ein asynchrones Ereignis aus, um das Token aus dem User Device Registry zu löschen. Web Push: Worker senden Web-Push-Protokollnachrichten unter Verwendung des VAPID-Standards. Die Push-Abonnementinformationen des Benutzers (Endpunkt-URL und Schlüssel) werden im User Device Registry (DynamoDB) gespeichert. Dieser Kanal verwendet dasselbe push-delivery-Topic mit einem Kanal-Subtyp-Feld. In-App-Benachrichtigungen: Für Benutzer, die gerade online sind, unterhalten wir persistente WebSocket-Verbindungen über eine API Gateway WebSocket API (AWS API Gateway WebSocket oder ein selbstverwalteter Dienst mit Socket.IO auf EKS). Eine Connection Registry (Redis Cluster) ordnet Benutzer-IDs WebSocket-Verbindungs-IDs zu. Der In-App-Zustellungsworker ruft die Verbindung ab und sendet die Benachrichtigung in Echtzeit, wenn der Benutzer verbunden ist. Wenn nicht verbunden, wird die Benachrichtigung in eine In-App-Inbox (DynamoDB-Tabelle, partitioniert nach Benutzer-ID, sortiert nach Zeitstempel) geschrieben und zugestellt, wenn der Benutzer die App das nächste Mal öffnet. Dieser Dual-Write stellt sicher, dass keine Benachrichtigung verloren geht, auch wenn der Benutzer offline ist. E-Mail und SMS: Kanäle mit niedrigerer Priorität. Worker konsumieren aus den E-Mail- und SMS-Delivery-Topics und rufen Amazon SES bzw. Amazon SNS (SMS) auf. Diese Kanäle haben eine höhere akzeptable Latenz (30 Sekunden bis Minuten), sodass sie konservativer skaliert werden können. Zustellungsgarantien: Mindestens einmalige Zustellung wird Ende-zu-Ende erreicht. Kafka-Konsumenten committen Offsets erst, nachdem die nachgelagerte Zustellungs-API den Empfang bestätigt hat (oder die Nachricht in der In-App-Inbox gespeichert wurde). Wenn ein Worker abstürzt, bevor er committet, wird die Nachricht erneut zugestellt. Der Idempotenzschlüssel in jeder Phase verhindert für den Benutzer sichtbare Duplikate. 6. Notification Status Tracking Ein leichtgewichtiger Statusdienst erfasst den Lebenszyklus jeder Benachrichtigung: erstellt, gesendet, zugestellt, gelesen. Zustellungsbestätigungen von FCM/APNs und Lesebestätigungen von der Client-App werden über ein Kafka-Topic aufgenommen und in einem Zeitreihen-Speicher (Amazon Timestream oder ClickHouse) für Analysen und in DynamoDB für benutzerspezifische Statusabfragen (damit die App Lese-/Ungelesen-Indikatoren anzeigen kann) geschrieben. Diese Daten fließen auch in die Wiederholungslogik ein: Wenn eine Push-Benachrichtigung nicht innerhalb von 30 Sekunden als zugestellt bestätigt wird, kann das System auf E-Mail zurückgreifen. 7. Observability Prometheus und Grafana überwachen Kafka-Consumer-Lag, Zustellungslatenz-Perzentile, Fehlerraten pro Kanal und Durchsatz. Alarme werden ausgelöst, wenn die p99-Zustellungslatenz 4 Sekunden überschreitet (was einen Puffer von 1 Sekunde vor dem 5-Sekunden-SLA gibt). Distributed Tracing (OpenTelemetry mit Jaeger) verfolgt ein Ereignis vom Producer bis zur Zustellung und ermöglicht eine schnelle Fehlersuche. Strukturierte Protokolle werden an Amazon OpenSearch zur Suche und Überprüfung gesendet. Anforderungen erfüllen Hoher Durchsatz: Kafka-partitionierte Topics und horizontal skalierte Consumer-Gruppen bewältigen 100.000 Benachrichtigungen pro Minute problemlos. Der Fan-out für große Kampagnen wird durch die Pufferung von Kafka absorbiert, und die Zustellungsworker skalieren automatisch basierend auf dem Lag. Niedrige Latenz: Der kritische Pfad für eine Benachrichtigung an einen einzelnen Benutzer (z. B. Bestellung versandt) ist: Producer veröffentlicht an Kafka (weniger als 50 ms), Notification Service konsumiert und reichert an (weniger als 100 ms einschließlich DynamoDB- und Redis-Lookups), Zustellungsworker sendet an FCM/APNs (typischerweise weniger als 500 ms). Insgesamt weit unter 5 Sekunden. Bei großen Fan-out-Kampagnen parallelisiert das System über viele Zustellungsworker; Kafka-Partitionierung stellt sicher, dass kein einzelner Worker ein Engpass ist. Zuverlässigkeit: Kafka-Replikation, Consumer-Offset-Management und idempotente Zustellung gewährleisten mindestens einmalige Semantiken. Eine Dead-Letter-Queue (DLQ)-Topic erfasst Nachrichten, die nach einer konfigurierbaren Anzahl von Wiederholungsversuchen fehlschlagen, und ein Betriebsteam wird benachrichtigt, um dies zu untersuchen. Kritische Bestellbenachrichtigungen werden mit einem Prioritätsfeld gekennzeichnet und an eine dedizierte Hochprioritäts-Partition mit eigener Consumer-Gruppe weitergeleitet, um sicherzustellen, dass sie niemals durch eine Flut von Werbebenachrichtigungen ausgehungert werden. Skalierbarkeit: Jede Komponente skaliert horizontal. Kafka-Partitionen können erhöht werden. Kubernetes-Pods skalieren automatisch. DynamoDB skaliert nach Bedarf. Es gibt keine Single Points of Failure oder Single-Threaded-Engpässe. Personalisierung: Benutzereinstellungen in DynamoDB steuern die Kanalauswahl und Ruhezeiten. Vorab berechnete Segmente ermöglichen gezielte Kampagnen. Der Template Service unterstützt pro-Locale-, pro-Kategorie-Nachrichten-Vorlagen, und A/B-Testvarianten können zur Anreicherungszeit ausgewählt werden. Wichtige Abwägungen und Begründungen Konsistenz vs. Verfügbarkeit: Das System bevorzugt Verfügbarkeit (AP in CAP-Begriffen). Wenn der Einstellungs-Speicher kurzzeitig nicht erreichbar ist, verwendet der Notification Service eine zwischengespeicherte oder Standardeinstellung, anstatt zu blockieren. Das bedeutet, dass ein Benutzer gelegentlich eine Benachrichtigung über einen Kanal erhält, den er gerade abbestellt hat, aber keine Benachrichtigung geht verloren oder wird verzögert. Für ein E-Commerce-Benachrichtigungssystem sind Verfügbarkeit und geringe Latenz wichtiger als strenge Konsistenz der Einstellungen. Mindestens einmal vs. Genau einmal: Echte Exactly-Once-Zustellung über externe Systeme (FCM, APNs) ist unpraktisch. Stattdessen garantieren wir mindestens einmalige Zustellung und verwenden Idempotenzschlüssel, um Duplikate auf Anwendungsebene zu unterdrücken. Dies ist einfacher, kostengünstiger und ausreichend. Verwaltete Dienste vs. Selbst gehostet: Wir verwenden verwaltetes Kafka (MSK), verwaltetes Kubernetes (EKS) und verwaltete Datenbanken (DynamoDB), um den Betriebsaufwand zu reduzieren. Der Kompromiss ist ein höherer Stückpreis im Vergleich zu selbst gehosteten Lösungen, aber die eingesparte Ingenieurszeit und die Zuverlässigkeit von verwalteten Diensten rechtfertigen dies in unserem Maßstab. Push vs. Pull für In-App: WebSockets (Push) bieten die geringste Latenz für Online-Benutzer, erfordern jedoch die Aufrechterhaltung persistenter Verbindungen und einer Verbindungsregistrierung. Polling wäre einfacher, würde aber Sekunden an Latenz hinzufügen und unnötige Last erzeugen. Der hybride Ansatz (WebSocket bei Online-Status, Inbox bei Offline-Status) gleicht Latenz und Ressourcennutzung aus. Kostenüberlegungen: Die größten Kostentreiber sind der Kafka-Durchsatz (MSK-Preisgestaltung), die DynamoDB-Lesekapazität für Einstellungsabfragen und die FCM/APNs-API-Aufrufe (kostenlos für FCM, aber die Infrastruktur, um sie in großem Maßstab aufzurufen, ist es nicht). Um die Kosten zu kontrollieren, bündeln wir FCM-Aufrufe, verwenden DynamoDB On-Demand-Preise (kostengünstig für sprunghafte Workloads) und nutzen Spot-Instanzen für nicht kritische Zustellungsworker (E-Mail, SMS). Schlussfolgerung Diese Architektur bietet ein robustes, skalierbares und latenzarmes Benachrichtigungssystem, das für eine E-Commerce-Plattform mit 50 Millionen Benutzern geeignet ist. Durch die Nutzung von Kafka als zentrales Nervensystem, DynamoDB für schnellen Zugriff auf Benutzerdaten und kanal-spezifische Zustellungsworker, die unabhängig voneinander skalieren, erfüllt das System alle angegebenen Anforderungen und bleibt gleichzeitig betrieblich überschaubar und kostengünstig. Das Design ist erweiterbar: Das Hinzufügen eines neuen Benachrichtigungskanals (z. B. WhatsApp) erfordert nur einen neuen Zustellungsworker, der aus einem neuen Kafka-Topic konsumiert, ohne Änderungen an den vorgelagerten Ereignisproduzenten oder der Kernverarbeitungslogik.