Event Sourcing ist ein Architekturmuster für verteilte Systeme, bei dem der aktuelle Zustand einer Entität nicht als veränderlicher Datenbankbestand gespeichert wird, sondern als lückenlose Folge unveränderlicher Ereignisse (Events). Jede Zustandsänderung wird als neues Ereignis an das Protokoll angehängt — die Ereignisliste ist die alleinige Quelle der Wahrheit.
Grundprinzip
Statt eines Kontostands speichert das System nur Ereignisse wie „Geld eingezahlt“ oder „Betrag überwiesen“. Der aktuelle Kontostand entsteht durch Replay aller Ereignisse in Reihenfolge. Der Ereignisspeicher (Event Store) ist dabei ein reines Anhänge-Protokoll (append-only): Bestehende Ereignisse werden nie verändert oder gelöscht.
Vorteile
- Vollständige Historie: Jede Änderung bleibt nachvollziehbar — ein natürlicher Audit-Trail.
- Replay und Debugging: Der Zustand jederzeit rekonstruierbar; Fehler lassen sich anhand der Ereignisfolge analysieren.
- Neue Sichten: Aus demselben Ereignisprotokoll lassen sich später neue Read Models oder Auswertungen erzeugen.
- Zeitreise: Historische Zustände (z.B. für Bug-Analysen) sind direkt verfügbar.
Herausforderungen
- Schema-Evolution: Ereignisformate müssen versioniert werden, damit alte Ereignisse weiterhin interpretierbar bleiben.
- Eventual Consistency: Abgeleitete Sichten sind erst nach Verarbeitung der Ereignisse aktuell.
- Komplexität: Das Muster erfordert andere Denk- und Testmuster als klassische CRUD-Anwendungen.
Event Sourcing wird häufig mit CQRS kombiniert: Der Ereignisspeicher dient als Schreibmodell, daraus werden eventual consistent Read Models aufgebaut. In verteilten Systemen und Microservice-Umgebungen ersetzt es oft klassische Datenbanken mit veränderlichem Zustand; als Speicher kommen häufig NoSQL-Systeme zum Einsatz.
Verwandte Grundlagen: Transactional Outbox (zuverlässige Ereignis-Veröffentlichung), Saga-Muster (Langlaufende Prozesse), Message Broker (Ereignis-Transport).