Event Sourcing

Event Sourcing ist ein Architekturprinzip, das sich darauf konzentriert, Zustandsänderungen eines Systems als eine Abfolge von Ereignissen zu speichern, anstatt den aktuellen Zustand direkt in einer Datenbank zu speichern. Diese Methode ermöglicht es, den vollständigen Verlauf der Änderungen nachzuvollziehen und das System in jedem beliebigen früheren Zustand wiederherzustellen.

Grundprinzipien von Event Sourcing

• Ereignisse als primäre Datenquelle: Anstatt den aktuellen Zustand eines Objekts oder einer Entität in einer Datenbank zu speichern, werden alle Änderungen an diesem Zustand als Ereignisse protokolliert. Diese Ereignisse sind unveränderlich und stellen die einzige Quelle der Wahrheit dar.

• Unveränderlichkeit: Einmal aufgezeichnete Ereignisse werden nicht verändert oder gelöscht. Dadurch wird eine vollständige Nachvollziehbarkeit und Reproduzierbarkeit des Systemzustands erreicht.

• Rekonstruktion des Zustands: Der aktuelle Zustand einer Entität wird durch das „Abspielen“ der Ereignisse in chronologischer Reihenfolge rekonstruiert. Jedes Ereignis enthält alle Informationen, die benötigt werden, um den Zustand zu verändern.

• Auditing und Historie: Da alle Änderungen als Ereignisse gespeichert werden, bietet Event Sourcing von Natur aus eine umfassende Audit-Historie. Dies ist besonders nützlich in Bereichen, in denen regulatorische Anforderungen an die Nachverfolgbarkeit und Überprüfbarkeit von Änderungen bestehen, wie z.B. im Finanzwesen.

Vorteile von Event Sourcing

1. Nachvollziehbarkeit und Auditfähigkeit:

   • Da alle Änderungen als Events gespeichert werden, kann der gesamte Änderungsverlauf eines Systems jederzeit nachvollzogen werden. Dies erleichtert Audits und ermöglicht es, den Zustand des Systems zu einem beliebigen Zeitpunkt in der Vergangenheit wiederherzustellen.

2. Erleichterung der Fehlerbehebung:

   • Bei Fehlern im System kann die Ursache leichter nachverfolgt werden, da alle Änderungen in Form von Ereignissen protokolliert werden.

3. Flexibilität in der Repräsentation:

   • Es ist einfacher, verschiedene Projektionen des gleichen Datenmodells zu erstellen, da man die Events auf unterschiedliche Weisen aggregieren oder darstellen kann.

4. Erleichterung der Integration mit CQRS (Command Query Responsibility Segregation):

   • Event Sourcing wird oft in Verbindung mit CQRS verwendet, um Lese- und Schreiboperationen zu trennen, was die Skalierbarkeit und Performance verbessern kann.

5. Leichtere Implementierung von Temporal Queries:

   • Da der gesamte Verlauf von Änderungen gespeichert ist, können komplexe zeitbasierte Abfragen einfach implementiert werden.

Nachteile von Event Sourcing

1. Komplexität der Implementierung:

   • Event Sourcing kann komplexer zu implementieren sein als traditionelle Speicherungsmethoden, da zusätzliche Mechanismen zur Ereignisverwaltung und -wiederherstellung erforderlich sind.

2. Ereignis-Schema-Entwicklung und -Migration:

   • Änderungen am Schema von Ereignissen erfordern eine sorgfältige Planung und Migrationsstrategien, um bestehende Ereignisse zu unterstützen.

3. Speicheranforderungen:

   • Da alle Ereignisse dauerhaft gespeichert werden, können die Speicheranforderungen im Laufe der Zeit erheblich steigen.

4. Potenzielle Performance-Probleme:

   • Das Abspielen einer großen Anzahl von Ereignissen, um den aktuellen Zustand zu rekonstruieren, kann zu Performance-Problemen führen, insbesondere bei großen Datensätzen oder Systemen mit vielen Zustandsänderungen.

Wie Event Sourcing funktioniert

Um Event Sourcing besser zu verstehen, schauen wir uns ein einfaches Beispiel an, das einen Kontoauszug in einer Bank simuliert:

Beispiel: Bankkonto

Stellen Sie sich vor, wir haben ein einfaches Bankkonto, und wir möchten dessen Transaktionen nachverfolgen.

1. Eröffnung des Kontos:

Event: KontoEröffnet
Data: {Kontonummer: 123456, Inhaber: "Max Mustermann", Anfangssaldo: 0}

2. Einzahlung von 100 €:

Event: EinzahlungGetätigt
Data: {Kontonummer: 123456, Betrag: 100}

3. Abhebung von 50 €:

Event: AbhebungGetätigt
Data: {Kontonummer: 123456, Betrag: 50}

Zustand rekonstruieren

Um den aktuellen Saldo des Kontos zu berechnen, werden die Ereignisse in der Reihenfolge, in der sie aufgetreten sind, „abgespielt“:

• Konto eröffnet: Saldo = 0
• Einzahlung von 100 €: Saldo = 100
• Abhebung von 50 €: Saldo = 50

Der aktuelle Zustand des Kontos ist somit ein Saldo von 50 €.

Verwendung von Event Sourcing mit CQRS

CQRS (Command Query Responsibility Segregation) ist ein Muster, das häufig zusammen mit Event Sourcing eingesetzt wird. Es trennt die Schreiboperationen (Commands) von den Leseoperationen (Queries).

• Commands: Aktualisieren den Zustand des Systems durch Hinzufügen neuer Ereignisse.
• Queries: Lesen den Zustand des Systems, der durch das Abspielen der Ereignisse in eine lesbare Form (Projektion) umgewandelt wurde.

Implementierungsdetails

Bei der Implementierung von Event Sourcing müssen einige Aspekte berücksichtigt werden:

1. Ereignisspeicher: Eine spezielle Datenbank oder ein Speichersystem, das alle Ereignisse effizient und unveränderlich speichern kann. Beispiele sind EventStoreDB oder relationale Datenbanken mit Event-Speicher-Schema.

2. Snapshotting: Um die Performance zu verbessern, werden häufig Snapshots des aktuellen Zustands in regelmäßigen Abständen erstellt, sodass nicht jedes Mal alle Ereignisse abgespielt werden müssen.

3. Ereignisverarbeitung: Ein Mechanismus, der die Ereignisse konsumiert und auf Änderungen reagiert, z.B. durch Aktualisierung von Projektionen oder Senden von Benachrichtigungen.

4. Fehlerbehandlung: Strategien zur Handhabung von Fehlern, die beim Verarbeiten von Ereignissen auftreten können, sind wichtig für die Zuverlässigkeit des Systems.

5. Versionierung: Änderungen an den Datenstrukturen erfordern eine sorgfältige Verwaltung der Versionskompatibilität der Ereignisse.

Verwendung in der Praxis

Event Sourcing wird in verschiedenen Bereichen und Anwendungen eingesetzt, insbesondere in komplexen Systemen mit hohem Änderungsbedarf und Anforderungen an die Nachvollziehbarkeit. Beispiele für den Einsatz von Event Sourcing sind:

• Finanzsysteme: Für die Verfolgung von Transaktionen und Kontobewegungen.
• E-Commerce-Plattformen: Für die Verwaltung von Bestellungen und Kundeninteraktionen.
• Logistik- und Lieferkettenmanagement: Für die Verfolgung von Lieferungen und Beständen.
• Microservices-Architekturen: Wo die Entkopplung von Komponenten und die asynchrone Verarbeitung wichtig sind.

Fazit

Event Sourcing bietet eine leistungsfähige und flexible Methode zur Verwaltung von Systemzuständen, erfordert jedoch eine sorgfältige Planung und Implementierung. Die Wahl, Event Sourcing zu verwenden, sollte auf den spezifischen Anforderungen des Projekts basieren, einschließlich der Notwendigkeit von Auditing, Nachvollziehbarkeit und komplexen Zustandsänderungen.

Hier ist eine vereinfachte visuelle Darstellung des Event Sourcing-Prozesses:

+------------------+       +---------------------+       +---------------------+
|    Benutzeraktion| ----> |  Ereignis erzeugen  | ----> |  Ereignisspeicher   |
+------------------+       +---------------------+       +---------------------+
                                                        |  (Speichern)         |
                                                        +---------------------+
                                                              |
                                                              v
+---------------------+       +---------------------+       +---------------------+
|   Ereignis lesen    | ----> |   Zustand rekonstru- | ----> |  Projektion/Query   |
+---------------------+       |     ieren           |       +---------------------+
                              +---------------------+