Das Logbuch der Wahrheit: Event Sourcing und CQRS verstehen

Fully AI-generated content. This article was generated using AI systems (e.g. Claude Code, Perplexity) and may contain errors or hallucinations.

← All articles

Software-Architekturen · 2026-06-21 · ca. 30 Minuten

Der Aufhänger: Was eine Bank besser macht als deine Datenbank

Stell dir vor, du fragst deine Bank, wie viel Geld auf deinem Konto liegt. Sie nennt dir einen Betrag – sagen wir 4.231,57 Euro. Jetzt stell dir vor, du fragst die Bank, warum es genau dieser Betrag ist. Eine seriöse Bank zuckt nicht mit den Schultern. Sie reicht dir einen Kontoauszug: eine lückenlose, chronologische Liste jeder einzelnen Buchung – Gehaltseingang, Lastschrift, Überweisung, Gebühr. Der Kontostand ist nicht die eigentliche Wahrheit. Die Wahrheit ist die Folge der Buchungen. Der Kontostand ist nur eine Zusammenfassung, die sich jederzeit aus dieser Folge neu berechnen lässt.

Und jetzt der unbequeme Vergleich: Die meisten Software-Systeme, die du und ich bauen, machen es genau umgekehrt. Sie speichern nur den Kontostand. In einer typischen Datenbank steht in einer Zeile kontostand = 4231.57. Kommt eine neue Buchung, wird dieser Wert mit UPDATE überschrieben – und der alte Wert ist für immer weg. Das System weiß was aktuell gilt, aber nicht mehr, wie es dahin kam. Es hat kein Gedächtnis, nur einen Zustand.

Event Sourcing dreht diese Logik um. Die Idee, die Martin Fowler 2005 prägnant beschrieben hat, lautet: Speichere nicht den aktuellen Zustand, sondern jede einzelne Zustandsänderung als unveränderliches Event in einer chronologischen, nur-anhängenden Sequenz. Der aktuelle Zustand ist dann kein gespeichertes Faktum mehr, sondern ein berechnetes Ergebnis – die Summe aller Events, so wie der Kontostand die Summe aller Buchungen ist.

Das klingt zunächst nach unnötigem Aufwand. Warum die ganze Historie aufheben, wenn man doch nur den aktuellen Wert braucht? Die Antwort ist überraschend tiefgreifend und reicht von vollständiger Auditierbarkeit über Zeitreisen im Code bis zu einer der elegantesten Antworten auf die Skalierungsprobleme moderner Cloud-Systeme. Dieser Artikel nimmt dich mit auf die ganze Strecke: vom Kernkonzept über den eng verwandten Partner CQRS, mehrere konkrete Beispiele aus der Praxis, eine ehrliche Bilanz der erheblichen Nachteile, bis zur Frage, wann du diese Muster einsetzen solltest – und, fast wichtiger, wann nicht.

Teil 1: Das Kernkonzept – Zustand als berechnetes Ergebnis

Der fundamentale Unterschied zu CRUD

Das vorherrschende Paradigma der Datenhaltung heißt CRUD: Create, Read, Update, Delete. Eine Entität – ein Kunde, eine Bestellung, ein Dokument – lebt als Datensatz in einer Tabelle. Ändert sich etwas, wird der Datensatz an Ort und Stelle modifiziert. Das ist einfach, intuitiv und für die überwältigende Mehrheit aller Anwendungen völlig ausreichend.

Der Preis dieser Einfachheit ist jedoch ein Informationsverlust bei jedem Schreibvorgang. Jedes UPDATE und jedes DELETE zerstört Information. Wenn ein Kunde seine Lieferadresse dreimal geändert hat, weiß ein CRUD-System nur die letzte. Die Zwischenschritte, der Zeitpunkt, der Grund – alles unwiederbringlich verloren, es sei denn, du hast es mühsam in zusätzlichen Audit-Tabellen mitprotokolliert.

Event Sourcing definiert die Grundeinheit der Wahrheit neu. Martin Fowler formuliert die Kernidee so: Jede Änderung am Zustand der Anwendung wird in einem Event-Objekt festgehalten, und diese Event-Objekte werden in der Reihenfolge gespeichert, in der sie angewendet wurden – und zwar für dieselbe Lebensdauer wie der Anwendungszustand selbst. Der Event Store wird damit zur einzigen Quelle der Wahrheit (Single Source of Truth). Er ist append-only: Events werden nur hinzugefügt, niemals geändert oder gelöscht. Ein einmal geschriebenes Event ist ein historisches Faktum, und Fakten ändert man nicht nachträglich.

Events sind Vergangenheit, Befehle sind Absicht

Eine sprachliche Feinheit, die das Verständnis enorm schärft: Events werden in der Vergangenheitsform benannt, weil sie etwas beschreiben, das bereits geschehen ist und nicht mehr abgelehnt werden kann. BestellungAufgegeben, ArtikelZumWarenkorbHinzugefuegt, LieferadresseGeaendert, ZahlungEingegangen. Ein Event hat keine Validierung mehr nötig – es ist die Aufzeichnung einer Tatsache.

Davon abzugrenzen ist der Command (Befehl): eine Absicht, etwas zu tun, formuliert in der Befehlsform – GibBestellungAuf, AendereLieferadresse. Ein Command kann scheitern. Die Geschäftslogik prüft ihn, und nur wenn er gültig ist, erzeugt er ein oder mehrere Events. Diese Unterscheidung – abweisbare Absicht versus unumstößliches Faktum – ist das konzeptuelle Rückgrat des gesamten Ansatzes.

Die Rekonstruktion: vom Event-Strom zum Zustand

Wenn nur Events gespeichert sind, wie kommt man an den aktuellen Zustand? Durch Replay: Man nimmt den Anfangszustand (typischerweise „leer") und wendet alle Events der betreffenden Entität der Reihe nach an. Jedes Event ist eine reine Funktion, die einen alten Zustand in einen neuen überführt. In funktionaler Notation ist der aktuelle Zustand schlicht eine Faltung (ein fold oder reduce) über den Event-Strom:

aktuellerZustand = events.reduce(anwenden, leererZustand)

Für ein Bankkonto: Starte bei 0, wende Eingezahlt(100) an → 100, wende Abgehoben(30) an → 70, wende Eingezahlt(50) an → 120. Der Kontostand 120 wurde nirgends gespeichert; er wurde errechnet. In C# könnte eine solche Aggregat-Rekonstruktion etwa so aussehen:

public Konto Rekonstruiere(IEnumerable<IEvent> events)
{
    var konto = new Konto();
    foreach (var e in events)
        konto.Wende(e);   // mutiert den Zustand pro Event
    return konto;
}

Snapshots gegen das Performance-Problem

Der aufmerksame Leser sieht sofort das Problem: Ein Konto mit 50.000 Buchungen müsste bei jedem Lesezugriff 50.000 Events durchlaufen. Das skaliert nicht. Die etablierte Lösung heißt Snapshot: In regelmäßigen Abständen (etwa alle 100 oder 500 Events) wird der vollständige berechnete Zustand als Momentaufnahme gespeichert, versehen mit der Versionsnummer des letzten enthaltenen Events. Bei der Rekonstruktion lädt man den jüngsten Snapshot und spielt nur noch die wenigen Events ab, die seither hinzukamen. Der Snapshot ist dabei reiner Cache – er enthält keine neue Information und kann jederzeit verworfen und neu berechnet werden. Die Wahrheit bleibt der Event-Strom.

Teil 2: CQRS – der natürliche Partner

Warum Lesen und Schreiben verschiedene Modelle brauchen

CQRS steht für Command Query Responsibility Segregation. Martin Fowler fasst den Kern so zusammen: Man kann ein anderes Modell für das Aktualisieren von Informationen verwenden als das Modell, mit dem man Informationen liest. In klassischen Architekturen nutzt man ein einziges Datenmodell für beides – dieselben Klassen, dieselben Tabellen, dieselbe Struktur für Schreiben und Lesen. CQRS bricht diese Symmetrie bewusst auf und trennt die Command-Seite (Schreiben, Zustandsänderungen, Validierung der Geschäftsregeln) sauber von der Query-Seite (Lesen, Anzeigen, Berichte).

Der Grund ist, dass die Anforderungen an beide Seiten oft diametral auseinanderlaufen. Die Schreibseite muss Geschäftsregeln durchsetzen, Konsistenz wahren und Konflikte behandeln – sie ist um Korrektheit organisiert. Die Leseseite muss schnell, denormalisiert und exakt auf die Bedürfnisse der jeweiligen Ansicht zugeschnitten sein – sie ist um Geschwindigkeit und Bequemlichkeit organisiert. Ein einziges Modell für beide Zwecke ist häufig ein fauler Kompromiss, der keiner Seite voll gerecht wird.

Die ideale Symbiose mit Event Sourcing

CQRS und Event Sourcing sind unabhängige Muster – man kann jedes ohne das andere einsetzen – aber sie ergänzen sich auffällig gut. Microsofts Azure Architecture Center beschreibt die übliche Kombination so: Event Sourcing wird häufig mit CQRS verbunden, indem die Datenverwaltungsaufgaben als Reaktion auf die Events ausgeführt werden und indem Views (Projektionen) aus den gespeicherten Events materialisiert werden.

Die Mechanik dahinter ist elegant. Die Command-Seite tut nichts anderes, als Events in den Store anzuhängen – das ist ein extrem schneller, konfliktarmer Vorgang. Im Hintergrund lauschen Projektionen auf diesen Event-Strom und bauen daraus optimierte Lesemodelle auf: eine relationale Tabelle für die Suche, ein denormalisiertes Dokument für die Detailansicht, ein Elasticsearch-Index für die Volltextsuche, eine vorberechnete Kennzahl für ein Dashboard. Aus einem Event-Strom lassen sich beliebig viele, je nach Anwendungsfall geformte Lesemodelle ableiten – und wenn ein neues Anzeigebedürfnis entsteht, baut man einfach eine neue Projektion und spielt die gesamte Historie hindurch.

Diese Trennung erlaubt es zudem, Lese- und Schreiblast unabhängig zu skalieren. In vielen Systemen überwiegen Lesezugriffe die Schreibzugriffe um Größenordnungen. Mit CQRS kann man die Query-Seite über viele Repliken horizontal skalieren, ohne die Schreibseite anzufassen – ein in der Cloud besonders wertvoller Hebel.

Der Preis: Eventual Consistency

Hier liegt der zentrale Haken, und es lohnt sich, ihn gnadenlos ehrlich zu benennen. Zwischen dem Moment, in dem ein Command ein Event in den Store schreibt, und dem Moment, in dem alle Projektionen dieses Event verarbeitet und ihre Lesemodelle aktualisiert haben, vergeht Zeit. In diesem Fenster zeigt die Leseseite einen veralteten Zustand. Das System ist nicht sofort, sondern nur letztendlich konsistent (eventually consistent).

Microsofts Architektur-Leitfaden ist hier unmissverständlich: Eventual Consistency zwischen Event Store und Projektionen ist dem Event Sourcing inhärent, weil das System erst dann konsistent ist, wenn es seine materialisierten Views durch das Abspielen der Events erzeugt hat. Konkret heißt das: Ein Nutzer gibt eine Bestellung auf, das Event ist sofort persistiert – aber die Bestellübersicht, die er als Nächstes sieht, zeigt die Bestellung womöglich noch nicht, weil die Projektion ein paar Millisekunden (oder unter Last länger) hinterherhinkt. Wer Event Sourcing mit CQRS einsetzt, muss dieses Verhalten im UX-Design und in den Geschäftsprozessen einplanen. Es ist keine Schwäche der Implementierung, sondern eine bewusste architektonische Abwägung – ein klassischer Fall des CAP-Theorems, bei dem man zugunsten von Verfügbarkeit und Partitionstoleranz auf sofortige Konsistenz verzichtet.

Teil 3: Konkrete Beispiele aus der Praxis

Beispiel 1: Der E-Commerce-Warenkorb

Betrachte einen Online-Warenkorb. Im CRUD-Modell speicherst du den aktuellen Inhalt – drei Artikel, bestimmte Mengen. Mehr weißt du nicht. Im Event-Sourcing-Modell speicherst du die Geschichte:

ArtikelHinzugefuegt(Buch, 1)
ArtikelHinzugefuegt(Stift, 5)
MengeGeaendert(Stift, 3)
ArtikelEntfernt(Buch)
GutscheinEingeloest("SOMMER10")

Der aktuelle Warenkorb (Stifte ×3, Gutschein aktiv) ergibt sich aus dem Replay. Aber jetzt kommt der geschäftliche Mehrwert, den CRUD niemals liefern könnte: Das Marketing kann auswerten, welche Artikel besonders oft wieder entfernt werden (ein Signal für Kaufabbrüche oder Preisschmerz). Es kann Warenkorbabbrüche analysieren, weil der gesamte Pfad zum Abbruch erhalten bleibt. Die Daten, die ein CRUD-DELETE einfach vernichtet hätte, sind hier ein wertvoller Analyseschatz. Diese Eigenschaft – dass fachlich interessante Information als Nebenprodukt der Architektur erhalten bleibt – ist einer der unterschätztesten Vorteile des Ansatzes.

Beispiel 2: Versionskontrolle als Event Store, den du täglich nutzt

Das vielleicht überzeugendste Beispiel hast du heute schon benutzt: Git. Ein Git-Repository speichert nicht den aktuellen Stand deiner Dateien als primäre Wahrheit. Es speichert eine append-only Sequenz von Commits – jeder Commit ist im Grunde ein Event („diese Änderungen wurden angewendet"). Der aktuelle Zustand deines Arbeitsverzeichnisses ist das Replay aller Commits bis zu einem bestimmten Punkt.

Daraus folgt unmittelbar, warum Git so mächtig ist: Du kannst zu jedem beliebigen historischen Zustand zurückreisen (git checkout), die komplette Historie inspizieren (git log), nachvollziehen, wer wann was und warum geändert hat (git blame), und alternative Realitäten parallel führen (Branches). All das sind direkte Konsequenzen der Event-Sourcing-Natur. Wenn du Git verstehst, verstehst du Event Sourcing bereits intuitiv – du hast es nur nie so genannt.

Beispiel 3: LMAX – Event Sourcing für extreme Performance

Ein häufiges Missverständnis lautet, Event Sourcing sei langsam. Das Gegenbeispiel ist legendär: die LMAX-Architektur, ebenfalls von Martin Fowler dokumentiert. LMAX ist eine Handelsplattform für Finanzprodukte, deren zentraler „Business Logic Processor" rund 6 Millionen Aufträge pro Sekunde auf einem einzigen Thread verarbeitet – vollständig im Arbeitsspeicher und auf Basis von Event Sourcing.

Der Clou: Weil der gesamte Zustand aus dem Event-Strom rekonstruierbar ist, muss der Verarbeitungskern überhaupt keine Datenbank während der Verarbeitung konsultieren. Er hält alles im RAM und gewinnt dadurch enorme Geschwindigkeit. Stürzt das System ab, wird der Zustand durch Replay der persistierten Events wiederhergestellt. Event Sourcing ist hier nicht trotz, sondern wegen der Performance-Anforderungen die richtige Wahl. Das Muster entkoppelt die teure Persistenz (sequenzielles Anhängen, sehr schnell) von der Geschäftslogik (im Speicher, ohne I/O-Wartezeiten).

Beispiel 4: Buchhaltung, das Urmuster

Die doppelte Buchführung wurde im 15. Jahrhundert kodifiziert und ist im Kern Event Sourcing avant la lettre. Ein Buchhalter radiert nie einen falschen Eintrag aus. Stattdessen bucht er eine Korrekturbuchung (Storno) – ein neues Event, das den Fehler ausgleicht. Die Historie bleibt unangetastet und prüfbar. Diese jahrhundertealte Disziplin ist der Grund, warum Event Sourcing in Finanz-, Versicherungs- und Compliance-Domänen so natürlich passt: Dort ist die lückenlose, unveränderliche Historie keine Kür, sondern gesetzliche Pflicht.

Teil 4: Die Superkräfte – was nur Event Sourcing kann

Über die einzelnen Beispiele hinaus lassen sich die strukturellen Vorteile in einer Übersicht bündeln.

Fähigkeit	Was sie bedeutet	Warum CRUD das nicht kann
Vollständiges Audit-Log	Jede Änderung ist mit Zeitpunkt, Auslöser und Kontext dauerhaft erfasst	CRUD überschreibt; Audit erfordert separate, fehleranfällige Zusatzmechanik
Zeitreise (Temporal Query)	Der Zustand zu jedem vergangenen Zeitpunkt ist rekonstruierbar	CRUD kennt nur das Jetzt
Debugging durch Replay	Ein Produktionsfehler lässt sich reproduzieren, indem man dieselben Events erneut abspielt	CRUD hat den fehlerverursachenden Pfad bereits vergessen
Neue Projektionen rückwirkend	Eine neue Auswertung wird über die gesamte Historie berechnet, auch über Daten, die vor ihrer Konzeption entstanden	CRUD kann nur ab dem Zeitpunkt sammeln, ab dem man daran gedacht hat
Retroaktive Korrektur	Fehlerhafte Logik kann korrigiert und die Historie mit der korrigierten Logik neu abgespielt werden	CRUD hat keine Ausgangsdaten für eine Neuberechnung

Besonders der Punkt neue Projektionen rückwirkend ist in der Praxis ein Gamechanger. In einem CRUD-System gilt der bittere Satz: „Daten, die wir nicht gesammelt haben, sind für immer verloren." Fragt das Management ein Jahr nach dem Launch nach einer Auswertung, an die beim Design niemand dachte, kann ein CRUD-System nur ab heute Daten sammeln. Ein Event-Sourcing-System baut die Auswertung über die volle Historie – als hätte man sie von Anfang an gehabt. Die Vergangenheit ist nicht vorbei; sie liegt im Event Store und wartet auf neue Fragen.

Teil 5: Die ehrliche Bilanz – die erheblichen Nachteile

Es wäre unseriös, Event Sourcing als Allheilmittel zu verkaufen. Martin Fowler selbst warnt bei CQRS ausdrücklich, dass es für die meisten Systeme riskante Komplexität hinzufügt und nur eingesetzt werden sollte, wenn ein klarer Nutzen die Mehrkosten rechtfertigt. Dieselbe Vorsicht gilt für Event Sourcing. Eine empirische Studie von Overeem und Kollegen (2021, basierend auf 19 produktiven Systemen und der Erfahrung von 25 Ingenieuren) hat die realen Schmerzpunkte präzise herausgearbeitet. Ich halte diese wissenschaftlich fundierte Bestandsaufnahme für wertvoller als die meist euphorischen Blogposts.

Schema-Evolution: das härteste Problem

Events sind unveränderliche Fakten und liegen oft jahrelang im Store. Nun ändern sich aber fachliche Anforderungen, und damit die Struktur der Events. Was tust du, wenn ein vor drei Jahren geschriebenes Event ein Feld nicht enthält, das deine heutige Logik erwartet? Du kannst die alten Events nicht einfach ändern – das würde das Grundprinzip verletzen. Die genannte Studie identifiziert die Evolution des Event-Systems als eine der größten Herausforderungen und nennt fünf etablierte Taktiken: versionierte Events, weak schema (tolerante Deserialisierung), Upcasting (alte Events beim Laden in die neue Form transformieren), In-Place-Transformation und Copy-and-Transform. Die Empfehlung der Forscher: mit versionierten Events und weak schema beginnen, später zu Upcasting übergehen. Doch egal welche Taktik – Schema-Evolution bleibt ein dauerhafter, anspruchsvoller Wartungsaufwand, der bei CRUD schlicht nicht existiert.

Steile Lernkurve und fehlende Werkzeuge

Dieselbe Studie nennt die steile Lernkurve und den Mangel an ausgereiften Technologien als weitere Kernprobleme. Event Sourcing erfordert ein fundamentales Umdenken – Entwickler, die jahrelang in CRUD gedacht haben, müssen Konzepte wie Aggregate, Projektionen, Idempotenz und Eventual Consistency neu verinnerlichen. Fehler in diesem Modell sind oft subtil und teuer. Hinzu kommt: Das Werkzeug-Ökosystem ist deutlich dünner und weniger standardisiert als für relationale Datenbanken. Es gibt spezialisierte Lösungen (etwa EventStoreDB, Marten für PostgreSQL im .NET-Umfeld oder Axon im Java-Umfeld), aber nichts mit der Reife, Verbreitung und Werkzeugdichte einer gewöhnlichen SQL-Datenbank.

Eventual Consistency als Dauerlast

Das in Teil 2 beschriebene Konsistenzfenster ist kein einmaliges Designproblem, sondern eine ständige Belastung für Entwicklung und Nutzererfahrung. Jede Funktion, die unmittelbar nach einem Schreibvorgang lesen will („Read-your-own-writes"), muss bewusst behandelt werden – etwa durch optimistische UI-Updates, durch Warten auf eine bestimmte Projektionsversion oder durch gezielte Ausnahmen von der Trennung. Das verkompliziert nahezu jeden Anwendungsfall.

Datenschutz und das Recht auf Vergessen

Ein in Europa besonders heikler Punkt, den auch die Studie als eigene Herausforderung („data privacy") führt: Die DSGVO gewährt ein Recht auf Löschung. Event Sourcing aber basiert auf einem unveränderlichen, nur-anhängenden Log – Löschen widerspricht dem Grundprinzip. Wie löscht man personenbezogene Daten aus einem Store, dessen Wesenskern die Unveränderlichkeit ist? Die übliche Antwort ist Crypto-Shredding: Man verschlüsselt personenbezogene Daten in den Events mit einem nutzerspezifischen Schlüssel und löscht im Bedarfsfall nur den Schlüssel. Die Events bleiben physisch erhalten, werden aber unentschlüsselbar und damit faktisch unzugänglich. Das ist eine elegante, aber nicht-triviale Zusatzkomplexität, die man von Anfang an mitplanen muss – und deren rechtliche Tragfähigkeit im Einzelfall sorgfältig zu prüfen ist.

Teil 6: Die entscheidende Frage – wann einsetzen, wann nicht?

Aus der Abwägung von Superkräften und Lasten ergibt sich eine pragmatische Entscheidungsregel. Sie ist wichtiger als jede technische Detailfrage.

Event Sourcing lohnt sich, wenn:

Die Domäne von Natur aus ereignisbasiert ist und die Historie selbst fachlichen Wert hat – Finanztransaktionen, Buchhaltung, Versicherungsfälle, Bestellabwicklung, Lagerbewegungen, medizinische Verläufe. Wenn Auditierbarkeit eine harte regulatorische Anforderung ist (Banken, Versicherungen, Gesundheitswesen). Wenn die Fähigkeit, vergangene Zustände zu rekonstruieren oder Verhalten rückwirkend zu analysieren, ein echter Geschäftsvorteil ist. Wenn extreme Schreib-Performance oder unabhängige Lese-Skalierung gefordert sind (wie bei LMAX).

Event Sourcing schadet, wenn:

Die Domäne im Kern simples CRUD ist – Stammdatenpflege, Benutzerprofile, Konfigurationsverwaltung, ein Content-Management-System. Hier ist die Historie meist irrelevant, und die zusätzliche Komplexität ist reiner Ballast ohne Gegenwert. Microsofts Leitfaden bringt es auf den Punkt: Event Sourcing muss keine Alles-oder-nichts-Entscheidung für das ganze System sein. Wende es selektiv auf die Teile an, die am meisten profitieren – etwa ein Zahlungsbuch oder eine Bestell-Pipeline – und nutze klassisches CRUD dort, wo die Komplexität nicht gerechtfertigt ist, etwa bei der Verwaltung von Benutzerprofilen oder Anwendungskonfiguration.

Genau hier zeigt sich die Reife eines Architekten. Die Verlockung, ein faszinierendes Muster überall anzuwenden, ist groß – und führt zu „Resume-Driven Development", bei dem die Architektur dem Lebenslauf des Entwicklers dient und nicht dem Problem. Ich bin der Meinung, dass die wertvollste Kompetenz nicht darin besteht, Event Sourcing implementieren zu können, sondern darin, ehrlich zu beurteilen, ob ein konkretes Subsystem es überhaupt braucht. In der Praxis bedeutet das fast immer: Event Sourcing nur für die wenigen, fachlich „heißen" Kerndomänen, klassisches CRUD für den großen Rest. Diese Hybrid-Strategie – ein Gedanke, der gut zu den Architektur-Abwägungen aus Ist die Cloud valide passt – ist die mit Abstand häufigste und gesündeste Form des Einsatzes.

Teil 7: Der Bezug zur Cloud und zu ereignisgetriebenen Systemen

Event Sourcing ist kein isoliertes Muster, sondern Teil einer größeren Bewegung hin zu ereignisgetriebenen Architekturen (Event-Driven Architecture), die in der Cloud-Ära besonders gut gedeiht. Die natürliche Append-only-Struktur passt hervorragend zu modernen Streaming-Plattformen wie Apache Kafka, zu Cloud-Diensten wie Azure Event Hubs oder AWS Kinesis und zu serverlosen, reaktiven Verarbeitungsmodellen.

Der tiefere Grund: In verteilten Cloud-Systemen ist die sofortige, globale Konsistenz ohnehin physikalisch teuer oder unmöglich. Eventual Consistency ist dort kein Sonderfall, sondern Normalität. Event Sourcing macht diese Realität explizit und beherrschbar, statt sie unter einer trügerischen Fassade scheinbarer Sofort-Konsistenz zu verstecken. Die Events werden zudem zum natürlichen Integrationsmechanismus zwischen Microservices: Ein Service veröffentlicht seine Events, andere Services reagieren darauf und bauen ihre eigenen Sichten – eine lose, robuste Kopplung. Damit wird der Event Store nicht nur zum Gedächtnis eines Dienstes, sondern zum Nervensystem einer ganzen Service-Landschaft.

Diese Verbindung von datenzentrierter Architektur und entkoppelter, reaktiver Verarbeitung ist auch der Punkt, an dem sich die Brücke zu modernen KI- und Datenpipelines schlagen lässt: Ein vollständiger Event-Strom ist ein idealer, lückenloser Trainings- und Analysedatensatz – ein Gedanke, der das Thema mit den Überlegungen aus Der Wettlauf mit der (um die) KI verknüpft.

Die zentrale Erkenntnis zum Mitnehmen

Event Sourcing ist im Kern eine einzige, tiefgreifende Umkehrung: Speichere nicht den Zustand, speichere die Geschichte – der Zustand ergibt sich dann von selbst. Diese Verschiebung der „Quelle der Wahrheit" vom aktuellen Wert hin zur unveränderlichen Ereignisfolge schenkt dir vollständige Auditierbarkeit, Zeitreisen, rückwirkende Auswertungen und robuste Skalierung – erkauft mit erheblicher Komplexität bei Schema-Evolution, Konsistenz, Werkzeugen und Datenschutz.

CQRS ist der natürliche Partner: die saubere Trennung von Schreib- und Lesemodell, die es erlaubt, aus einem Event-Strom beliebig viele optimierte Sichten zu materialisieren und Lese- wie Schreiblast unabhängig zu skalieren – um den Preis der Eventual Consistency.

Die wichtigste Lektion ist jedoch eine architektonische Haltung: Diese Muster sind scharfe Spezialwerkzeuge, kein Standard-Hammer. Ihr Wert entsteht nur dort, wo die Historie selbst fachlich zählt. Überall sonst sind sie teurer Ballast.

Konkreter Handlungsanstoß für diese Woche: Nimm dir ein System, das du gut kennst, und stelle eine einzige Frage – „Bei welcher Entität in diesem System würde es uns echten Geschäftswert bringen, nicht nur den aktuellen Stand, sondern die vollständige Änderungshistorie zu kennen?" Findest du eine überzeugende Antwort (typischerweise rund um Geld, Verträge, Bestände oder regulierte Vorgänge), hast du einen realen Kandidaten für Event Sourcing identifiziert. Findest du keine, hast du gerade bestätigt, dass CRUD die richtige, ehrliche Wahl ist – auch das ist ein wertvolles Ergebnis.

Reflexionsfrage: Welche wertvollen Informationen vernichten deine aktuellen Systeme bei jedem UPDATE und DELETE, ohne dass es jemandem auffällt – und welche Frage könnte dir in zwei Jahren gestellt werden, die du heute nur deshalb nicht beantworten kannst, weil du die Vergangenheit weggeworfen hast?

Querverweise im Vault

Ist die Cloud valide – Architektur- und Vertrauensfragen in der Cloud; die Hybrid-Strategie (Event Sourcing nur für Kerndomänen) ist eine direkte Anwendung des dort diskutierten Abwägens von Nutzen und Risiko.
Der Wettlauf mit der (um die) KI – Ein vollständiger Event-Strom ist ein idealer, lückenloser Datensatz für Analyse und KI-Training; datenzentrierte Architektur und KI greifen ineinander.
Spukhafte Fernwirkung: Quantenverschränkung von Einstein zum Quanteninternet – Auch dort spielt Konsistenz über Distanz und die Grenzen sofortiger Information eine zentrale Rolle; das CAP-Theorem ist gewissermaßen das „No-Signaling-Theorem" der verteilten Systeme.

Quellen und zum Weiterlesen

Martin Fowler – Event Sourcing (eaaDev, 2005): https://martinfowler.com/eaaDev/EventSourcing.html
Martin Fowler – CQRS (bliki): https://martinfowler.com/bliki/CQRS.html
Microsoft Learn – Event Sourcing Pattern (Azure Architecture Center): https://learn.microsoft.com/en-us/azure/architecture/patterns/event-sourcing
Martin Fowler – The LMAX Architecture: https://martinfowler.com/articles/lmax.html
Overeem, Spoor, Jansen, Brinkkemper – An Empirical Characterization of Event Sourced Systems and Their Schema Evolution — Lessons from Industry (Journal of Systems and Software, 2021): https://www.sciencedirect.com/science/article/pii/S0164121221000674 (Preprint: https://arxiv.org/abs/2104.01146)
Microsoft Learn – Event-Driven Architecture Style (Azure Architecture Center): https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/event-driven

Erstellt im Rahmen des täglichen Lern-Workflows. Interessensgebiet: Software-Architekturen. Geschätzte Lesedauer: ~30 Minuten.

← All articles