Event Sourcing ohne Angst: wann es sich lohnt und wann nicht

Event Sourcing hat einen schlechten Ruf. Wer den Begriff zum ersten Mal hört, denkt an komplexe Systeme, teure Migrationen und Teams, die Monate brauchen, um ein neues Konzept zu verstehen. Der Ruf ist nicht ganz unverdient — er ist aber vor allem ein Problem der falschen Anwendung.

In vielen Fällen wird Event Sourcing als architektonische Philosophie eingeführt, statt als Datenhaltungsstrategie für ein konkretes Problem. Das führt zu Systemen, die einfache Dinge umständlich machen, weil jedes Update zu einem Ereignis erhoben wird, ob es nun passt oder nicht.

Was Event Sourcing wirklich ist

Event Sourcing speichert nicht den aktuellen Zustand als primäre Wahrheit. Stattdessen speichert es die Veränderungen, die zu diesem Zustand geführt haben: Ereignisse. Der aktuelle Zustand ist eine Projektion dieser Ereignisse.

Das ist ein Unterschied, der vor allem in drei Situationen wertvoll ist:

• Audit und Nachvollziehbarkeit: Jede Änderung ist dokumentiert, wer was wann getan hat, lässt sich rekonstruieren — nicht als Zusatzfeature, sondern als Kern der Datenhaltung.
• Temporale Fragestellungen: Was war der Zustand gestern um 14 Uhr? Wie hätte sich das System verhalten, wenn Ereignis X nicht eingetreten wäre?
• Komplexe Domänen: Wenn das Geschäft selbst aus Ereignissen besteht — Bestellungen, Zahlungen, Genehmigungen, Lieferungen — ist ein Ereignisstrom oft die natürlichere Repräsentation als eine Tabelle mit dem letzten Stand.

Wann es sich lohnt

Der klassische Fall ist ein Fachsystem, dessen Zustand sich aus einer Kette von Geschäftsereignissen ergibt und bei dem die Historie nicht verloren gehen darf. Ein Beispiel aus der Praxis: Ein Zahlungsdienstleister, der jede Autorisierung, jede Buchung und jeden Rückbuchungsversuch protokollieren muss. Ein klassisches CRUD-Modell würde hier entweder eine separate Audit-Tabelle erfinden oder den aktuellen Zustand überschreiben und das Audit als Beilage führen. Event Sourcing macht die Historie zur primären Wahrheit.

Ein weiterer guter Fall: Systeme, in denen verschiedene Lesemodelle aus denselben Daten gebraucht werden. Weil der Zustand projiziert wird, kann ein Team mehrere Sichten auf dieselbe Ereignisquelle aufbauen, ohne die Datenhaltung neu zu erfinden.

Und schließlich: Domänen, in denen das Geschäft in Ereignissen denkt. Wenn Fachbereich und Team gemeinsam ein Event Model erstellen, ist der Schritt zu einem event-gesteuerten System oft kleiner als erwartet — weil die Sprache bereits übereinstimmt.

Wann es nicht passt

Die häufigste Fehlanwendung ist: ein System, das vor allem Daten verwaltet, in denen der aktuelle Zustand ausreicht und die Historie keine Geschäftsrelevanz hat. Benutzerprofile, Artikelkataloge, Konfigurationsdaten — hier wird Event Sourcing zur Last, ohne einen Mehrwert zu bringen.

Ein weiterer schlechter Moment: das Team hat keine Erfahrung mit eventual consistency, asynchroner Kommunikation und verteilten Systemen. Event Sourcing verschärft jeden dieser Aspekte. Wer Schwierigkeiten hat, ein gutes Datenbankschema zu entwerfen, wird mit Ereignisstrom, Projektionen und Konsistenzmodellen nicht glücklicher.

Und dann gibt es noch die Big-Bang-Migration: Ein Monolith, der seit zehn Jahren läuft, soll komplett auf Event Sourcing umgestellt werden. Das ist in der Regel keine technische Entscheidung, sondern eine politische. Sie ist teuer, langwierig und riskant. Besser ist eine geführte Modernisierung in Scheiben, bei der Event Sourcing dort eingeführt wird, wo es wirklich passt.

EventSourcingDB als pragmatische Basis

Wer sich für Event Sourcing entscheidet, braucht eine Datenbank, die das Modell nativ unterstützt, statt es auf einer relationalen Datenbank nachzubauen. EventSourcingDB von the native web ist genau das: eine Datenbank, die um den Ereignisstrom herum gebaut ist, mit Unterstützung für Projektionen, Subscriptions und Replikation.

KAIHITO setzt EventSourcingDB dort ein, wo die Fachlichkeit event-getrieben ist und wo die Operationalisierung einer Event-Sourcing-Lösung im eigenen Betrieb zu aufwändig wäre. In Kombination mit einem klaren Event Model und einer definierten Ownership-Struktur lässt sich damit ein System bauen, das sich betreiben und weiterentwickeln lässt, ohne dass das Team ein spezialisiertes Framework-Experte werden muss.

Wann ein Event Model ausreicht

Nicht jedes Vorhaben braucht Event Sourcing als Datenhaltung. Oft reicht es, das Geschäft als Ereignisstrom zu modellieren — als gemeinsame Sprache zwischen Fachbereich und Team. Ein Event-Modeling-Sprint bringt diese Sprache an den Tisch, ohne dass sofort eine technische Infrastruktur entschieden werden muss. Wenn sich später herausstellt, dass die Historie der Daten tatsächlich wichtig ist, ist der Weg zu Event Sourcing bereits vorbereitet.

Kurzfassung

Event Sourcing lohnt sich, wenn Historie, Audit und temporale Fragen zentral für das Geschäft sind. Es ist keine allgemeine Architekturverbesserung und keine Antwort auf unklare Domänen. Wer es dort einsetzt, wo es passt, und wer es mit einem klaren Event Model sowie einer event-native Datenbank wie EventSourcingDB betreibt, gewinnt Nachvollziehbarkeit und Flexibilität. Wer es überall einsetzt, bezahlt Komplexität ohne Mehrwert.