Einführung in Event Sourcing und CQRS

Event Sourcing und Command Query Responsibility Segregation (CQRS) sind zu grundlegenden Mustern für den Aufbau moderner, verteilter Systeme geworden. In Kombination mit serverlosen Architekturen ermöglichen diese Muster eine beispiellose Skalierbarkeit, Resilienz und Auditierbarkeit. Dieser Artikel bietet eine gründliche Untersuchung der Implementierung von Event Sourcing und CQRS in serverlosen Umgebungen, wobei Kernkonzepte, praktische Implementierungsstrategien, häufige Fallstricke und bewährte Praktiken der realen Welt behandelt werden.

Event Sourcing: Speichern von Change als Sequenz von Events

Event Sourcing ist ein Datenpersistenzmuster, bei dem jede Änderung des Anwendungszustands als unveränderliches Ereignis erfasst wird. Anstatt nur den aktuellen Zustand zu speichern, zeichnet das System ein chronologisches Protokoll der Ereignisse auf. Der aktuelle Zustand kann durch Wiedergabe dieser Ereignisse rekonstruiert werden. Dieser Ansatz bietet einen vollständigen Audit-Trail, ermöglicht zeitliche Abfragen (z. B. "Wie war der Zustand zu einem bestimmten Datum?") und vereinfacht das Debuggen und die Einhaltung.

In einem serverlosen Kontext muss der Event-Store sehr langlebig, skalierbar und latenzarm sein. Übliche Auswahlmöglichkeiten sind AWS DynamoDB, Azure Cosmos DB oder Google Cloud Firestore. DynamoDB passt mit seinem On-Demand-Kapazitätsmodus natürlich in serverlose Abrechnungsmodelle und kann Ereignisströme mit jedem Volumen verarbeiten. Ereignisdaten werden normalerweise in einer Tabelle mit einem Primärschlüssel gespeichert, der eine aggregierte Kennung und eine Versionsnummer enthält, um Ordnung und Idempotenz zu gewährleisten.

Martin Fowlers kanonischer Artikel über Event Sourcing bleibt eine definitive Referenz für das Verständnis der Nuancen des Musters.

Ereignisstruktur und Schema

Jedes Ereignis sollte mindestens einen Ereignistyp, einen Zeitstempel, eine aggregierte Kennung, eine Versionsnummer und eine Nutzlast mit den geänderten Daten enthalten. Die Verwendung einer Schemaregistrierung (z. B. Google Cloud Schema Registry oder AWS EventBridge Schema Registry) hilft, die Abwärtskompatibilität bei sich entwickelnden Ereignissen aufrechtzuerhalten.

CQRS: Trennung von Lesevorgängen von Schreibvorgängen

CQRS (Command Query Responsibility Segregation) entkoppelt die Modelle, die für die Verarbeitung von Befehlen (writes) verwendet werden, von denen, die für die Verarbeitung von Abfragen (reads) verwendet werden. In einer serverlosen Architektur bedeutet dies die Bereitstellung separater Funktionen oder Dienste: Befehlshandler verarbeiten Schreibvorgänge, die häufig Ereignisse an den Ereignisspeicher anhängen, während Abfragehandler aus optimierten Lesemodellen lesen - typischerweise denormierte Tabellen, materialisierte Ansichten oder Suchindizes.

Diese Trennung bringt erhebliche Vorteile: Schreib-Workloads bleiben schlank und konzentrieren sich auf Validierung und Ereignis-Persistenz, während Lesemodelle für einen schnellen Abruf, einschließlich Pre-Joins, Aggregationen und Volltext-Suchfunktionen, abgestimmt werden können. Die beiden Seiten kommunizieren über asynchrone Mechanismen wie eventstreams oder message-Warteschlangen (z. B. AWS SQS, Azure Queue Storage, Google Cloud Tasks).

Greg Youngs originale CQRS Dokumentation bietet einen grundlegenden Kontext für das Muster.

Kombination von Event Sourcing und CQRS in Serverless

Wenn Event Sourcing und CQRS zusammen verwendet werden, bilden sie ein leistungsstarkes Duo: Befehle erzeugen Ereignisse, die im Ereignisprotokoll gespeichert sind, und Projektionen (oder Abonnenten) aktualisieren asynchron Lesemodelle. Serverlose Plattformen zeichnen sich durch dieses ereignisgesteuerte Paradigma aus, weil sie das Infrastrukturmanagement abstrahieren und jede Komponente automatisch auf der Grundlage der Last skalieren.

Unten ist ein typischer serverloser Event-Sourced-Systemfluss:

  1. User action löst eine Befehlsfunktion aus (z.B. ein AWS Lambda hinter API Gateway).
  2. Die Befehlsfunktion validiert die Eingabe, erzeugt ein oder mehrere Domänenereignisse und fügt sie dem Ereignisspeicher (DynamoDB, Cosmos DB, etc.) hinzu.
  3. Nach dem Anfügen der Ereignisse veröffentlicht die Funktion eine Nachricht (z. B. an Amazon EventBridge, Azure Event Grid oder Google Pub/Sub), die anzeigt, dass neue Ereignisse verfügbar sind.
  4. Projection functions abonnieren den Ereignisstrom und aktualisieren das gelesene Modell (z.B. eine denormalisierte DynamoDB-Tabelle, einen Elasticsearch-Index oder einen Cache wie Redis).
  5. Abfragefunktionen dienen Leseanforderungen direkt aus dem gelesenen Modell und stellen niemals eine Abfrage des Ereignisspeichers dar.

Dieses Design gewährleistet eventuale Konsistenz zwischen der Schreib- und Leseseite, was ein Kern-Kompromiss von CQRS ist. In vielen Geschäftsbereichen ist eine eventuelle Konsistenz akzeptabel und sogar wünschenswert, weil sie einen höheren Durchsatz und eine geringere Latenz für Lesevorgänge ermöglicht.

Beispiel: E‐Commerce Order Management

Betrachten wir ein Bestellsystem. Ein Benutzer gibt eine Bestellung (Befehl) ab, die ein -Ereignis ausgibt. Eine Projektionsfunktion liest dieses Ereignis und aktualisiert ein Bestellzusammenfassungslesemodell, das den Produktnamen, die Menge und den aktuellen Status enthält. Eine andere Projektion aktualisiert möglicherweise ein Bestandslesemodell. Wenn der Benutzer später den Bestellverlauf anfordert, liest die Abfragefunktion aus dem vorgefertigten Zusammenfassungsmodell, wodurch teure Verknüpfungen oder Lesevorgänge aus dem Rohereignisspeicher vermieden werden.

Implementierung des Event Stores in Serverlosen Datenbanken

Design-Entscheidungen für den Event-Store haben direkte Auswirkungen auf Leistung und Kosten. Bei DynamoDB ist ein gängiger Ansatz, eine einzelne Tabelle mit einem zusammengesetzten Primärschlüssel zu verwenden: (Partitionsschlüssel) und (Sortierschlüssel). Dies ermöglicht ein schnelles Abrufen aller Ereignisse für ein bestimmtes Aggregat in der Reihenfolge. Das Speichern des gesamten Ereignisstroms in einem einzelnen Partitionsschlüssel stellt sicher, dass Vorgänge wie Snapshotting (periodische Speicher des Aggregatzustands) effizient bleiben.

Bei Workloads, die übergreifende Abfragen erfordern, sollten Sie einen sekundären Index für den Ereignistyp oder den Zeitstempel verwenden, vermeiden Sie jedoch das Scannen des gesamten Ereignisspeichers; solche Bedürfnisse werden durch dedizierte Lesemodelle besser erfüllt.

In Azure bietet Cosmos DB ähnliche Funktionen mit konfigurierbaren Konsistenzstufen und automatischer Indexierung. Das Ereignis-Sourcing-Muster des Azure Architecture Centers bietet spezielle Anleitungen für diese Plattform.

Gleichzeitigkeit und Idempotenz

Concurrent Writes auf dasselbe Aggregat müssen sorgfältig behandelt werden. Mit optimistischer Konkurrenzsteuerung (z. B. bedingte Aktualisierung mit Versionsüberprüfung in DynamoDB) wird sichergestellt, dass nur ein Befehl pro Versionsinkrement erfolgreich ist. Im Falle eines Konflikts kann der Befehl nach erneutem Lesen der neuesten Ereignisse erneut versucht werden. Die Idempotenz wird durch die Speicherung einer eindeutigen Kennung (z. B. einer Korrelations-ID) mit jedem Ereignis sichergestellt, so dass der Befehlshandler Duplikate erkennen und anmutig ablehnen kann.

Building Read Modelle mit Projektionen

Projektionen sind Funktionen, die Ereignisse verbrauchen und ein oder mehrere gelesene Modelle aktualisieren. In serverlosen Fällen werden sie am besten als ereignisgesteuerte Funktionen implementiert, die vom Ereignisbus ausgelöst werden. Jede Projektionsfunktion sollte idempotent sein: Wenn ein Ereignis mehr als einmal verarbeitet wird (z. B. aufgrund eines Wiederholungsversuchs), muss das gelesene Modellupdate das gleiche Ergebnis liefern.

Gemeinsame Strategien zum Erstellen von Lesemodellen umfassen:

  • Denormalisierte Tabellen in DynamoDB oder Cosmos DB, die die Abfragemuster widerspiegeln (z. B. alle Bestellungen für einen Benutzer).
  • Search-Indizes in Elasticsearch, Amazon OpenSearch oder Azure Search für Volltext- und Facettenabfragen.
  • Materialisierte Ansichten mit Streaming-Frameworks wie AWS Kinesis Data Analytics oder Azure Stream Analytics.
  • In‐Memory-Caches (z. B. ElastiCache, Redis) für Abfragen mit extrem niedriger Latenz, mit TTL‐basierter Ungültigkeit.

Um eine enge Kopplung zu vermeiden, sollten die Vorsprünge zustandslos sein und ausschließlich durch die Nutzlast des Ereignisses angetrieben werden; sie können hinzugefügt, entfernt oder geändert werden, ohne die Befehlsseite zu beeinträchtigen.

Umgang mit eventuellen Konsistenz- und SAGA-Anforderungen

Eine der größten Herausforderungen in einem CQRS/ES-System besteht darin, die eventuelle Konsistenz zu verwalten und mehrstufige Geschäftstransaktionen zu koordinieren. Ein Benutzer kann eine Bestellung aufgeben, das gelesene Modell spiegelt diese Änderung jedoch möglicherweise für einige hundert Millisekunden nicht wider. Bei synchronen Benutzererwartungen (z. B. Anzeigen einer Bestätigungsseite) kann der Befehlsbearbeiter die Ereignis-ID sofort zurückgeben, während das Frontend für das gelesene Modell aktualisiert wird oder einen WebSocket-Kanal abonniert.

Für mehrstufige Prozesse, die verteilte Transaktionen erfordern, ist das SAGA-Muster die bevorzugte Lösung. Jeder Schritt in der Saga sendet Ereignisse aus, und Kompensationsereignisse werden im Ereignisspeicher gespeichert, um teilweise abgeschlossene Schritte rückgängig zu machen. Serverlose Funktionen und dauerhafte Orchestratoren (z. B. AWS Step Functions, Azure Durable Functions, Google Workflows) können Sagas zuverlässig ohne lang laufende Sperren implementieren.

Fehlerbehandlung und Idempotenz auf einer Skala

Serverlose Umgebungen unterliegen vorübergehenden Ausfällen und doppelten Aufrufen. Ereignis-Handler müssen auf Idempotenz ausgelegt sein. Speichern Sie ein Deduplizierungsfenster (z. B. mit DynamoDB TTL oder einem Redis-Set), das verarbeitete Ereignis-IDs aufzeichnet. Wenn ein Ereignis erneut innerhalb des Fensters eintrifft, wird es stillschweigend ignoriert.

Wenn ein Befehl nach dem Anfügen von Ereignissen an den Speicher fehlschlägt, sind die Ereignisse bereits geschrieben. In solchen Fällen müssen Sie möglicherweise ein ]kompensierendes Ereignis implementieren (z. B. ), um den Zustand zurückzusetzen. Das kompensierende Ereignis wird wie ein normales Ereignis gespeichert und löst eine Projektion aus, die die Arbeit rückgängig macht.

Betrachten Sie auch dead-letter-Warteschlangen (DLQs) für Ereignisse, die wiederholt fehlschlagen Verarbeitung. DLQs ermöglichen es Ihnen, Ereignisse zu inspizieren und zu wiederholen, nachdem das Problem behoben wurde, ohne Daten zu verlieren.

Performance- und Kostenoptimierung in Serverlosen Eventsystemen

Während Serverless automatisch skaliert, kann das nachlässig gestaltete Event Sourcing hohe Kosten verursachen.

  • Batch-Verarbeitung: Beim Projizieren von Ereignissen lesen und schreiben Sie in Batches, um Datenbankanforderungen zu minimieren. DynamoDBs kann bis zu 25 Elemente gleichzeitig verarbeiten.
  • Snapshots: Speichern Sie regelmäßig Snapshots von Aggregatzuständen, um zu vermeiden, dass das gesamte Ereignisprotokoll bei jedem Lesen wiedergegeben wird. Snapshots werden in derselben Ereignisspeichertabelle mit einer speziellen Version (z. B. Versionsnummer, der "SNAP" vorangestellt wird) gespeichert. Die Wiedergabelogik beginnt dann mit dem neuesten Snapshot und reduziert die Lesezeit drastisch.
  • Caching: Cache griff häufig auf gelesene Modelldaten auf Anwendungsebene zu (z.B. mit ElastiCache oder CloudFront mit dynamischen Inhalten).
  • Event-Partitionierung: Wenn Sie ein Pub/Sub-System wie EventBridge verwenden, partitionieren Sie Ereignisse nach Aggregattyp, um die Invokationsrate für Projektionsfunktionen zu steuern.

Beispiel: Snapshot-Strategie in DynamoDB

Speichern eines Snapshots mit Partitionsschlüssel = aggregateId und Sortierschlüssel = „SNAP# Die Nutzlast enthält den vollständig rekonstruierten Zustand. Beim Abrufen des aktuellen Zustands Abfrage nach Ereignissen mit Sortierschlüssel, der größer ist als die Snapshot-Version, wodurch die Anzahl der zu verarbeitenden Ereignisse reduziert wird. Typische Snapshot-Frequenz ist alle 50-100 Ereignisse oder basierend auf der Zeit (z. B. alle 5 Minuten).

Testen und Debuggen von ereignisbasierten Serverlosen Systemen

Das Testen von ereignisgesteuerten Architekturen erfordert andere Strategien als herkömmliche CRUD-Systeme. Unit-Tests können überprüfen, ob Befehlshandler bei Eingabe die richtigen Ereignisse erzeugen. Integrationstests sollten validieren, dass Projektionen gelesene Modelle bei der Veröffentlichung der Ereignisse korrekt aktualisieren. Da serverlose Funktionen zustandslos sind, sollten Sie lokale Emulatoren (z. B. AWS SAM local, DynamoDB Local, EventBridge local testing library) verwenden, um Tests in CI/CD-Pipelines durchzuführen.

Das Debuggen von Produktionsproblemen profitiert vom Ereignisprotokoll selbst – Sie können Ereignisse in einer Entwicklungsumgebung wiedergeben, um die genaue Sequenz, die zu einem Fehler geführt hat, nachzuvollziehen. Tools wie AWS X‐Ray oder Azure Monitor helfen, Funktionsaufrufe über Dienste hinweg zu verfolgen.

Häufige Fallstricke und wie man sie vermeidet

  • Unangemessene Domain-Modellierung: Nicht jede Business-Domain profitiert von Event-Sourcing. Wenn Sie einfaches CRUD ohne Audit-Anforderungen benötigen, ist der Overhead möglicherweise nicht gerechtfertigt.
  • Übergroße Ereignisse: Die Speicherung großer Nutzlasten (z. B. gesamte Dokumente) als einzelnes Ereignis reduziert die Leistung. Zerlegen Sie Ereignisse in sinnvolle, granulare Änderungen.
  • Projektionsdrift: Wenn Lesemodelle aufgrund von verpassten Ereignissen oder Fehlern nicht synchronisiert werden, benötigen Sie einen Wiedergabemechanismus.
  • Das Ignorieren der Schemaentwicklung: Ereignisse sind unveränderlich, aber ihre Schemata ändern sich. Verwenden Sie eine Registrierung und Version jedes Ereignistyps. Entwerfen Sie neue Projektionen, um mehrere Versionen zu verarbeiten.
  • Kaltstarts beeinflussen Projektionen: Projektionsfunktionen, die selten aufgerufen werden, können unter Kaltstartlatenz leiden.

Real-World Architekturbeispiel

Eine Finanzhandelsanwendung, die auf AWS Lambda, DynamoDB und EventBridge basiert, implementierte Event Sourcing, um jede Handelsorder aufzuzeichnen. Befehlsfunktionen bearbeiteten Kauf-/Verkaufsaufträge und emittierten , und Ereignisse. Projektionen aktualisierten eine DynamoDB-Tabelle für das Portfolio des Benutzers und ein Elasticsearch-Cluster für Echtzeit-Marktanalysen. Das System verarbeitete über 10.000 Ereignisse pro Sekunde während der Hauptverkehrszeiten mit 99,99% Verfügbarkeit und einer Latenz unterhalb von Sekunden für Portfolioabfragen dank Snapshotting und effizientem Lesemodelldesign.

Dieses Team vermied häufige Fallstricke, indem es eine strenge Ereignisschemaversionierung (mit Apache Avro) durchsetzte und eine dedizierte Replay-Pipeline implementierte, die alle gelesenen Modelle in weniger als 30 Minuten von Grund auf neu erstellen konnte.

Schlussfolgerung

Die Implementierung von Event Sourcing und CQRS in serverlosen Architekturen gibt Entwicklungsteams die Möglichkeit, hochskalierbare, überprüfbare und wartbare Systeme zu erstellen. Durch die Nutzung vollständig verwalteter Dienste für Ereignisspeicherung, Nachrichtenrouting und Berechnung können Sie sich auf die Geschäftslogik konzentrieren, während die Plattform Infrastrukturprobleme behandelt. Zu den wichtigsten Erfolgsfaktoren gehören sorgfältige Ereignismodellierung, idempotente Projektionen, Snapshot-Optimierung und robuste Fehlerbehandlung. Mit diesen Praktiken werden Event Sourcing und CQRS zu leistungsstarken Werkzeugen für die Bewältigung komplexer Geschäftsdomänen in der Cloud.