Einführung
Event Sourcing ist eines jener Architekturmuster, die in der Theorie fantastisch klingen, in der Praxis aber herausfordernd sein können. Nach zwei Jahren Betrieb eines Event-Sourced-Zahlungssystems in Produktion habe ich gelernt, wann sich der Aufwand lohnt und wann nicht.
Was ist Event Sourcing?
Statt den aktuellen Zustand der Daten zu speichern, speichert Event Sourcing eine Abfolge von Ereignissen, die zu diesem Zustand geführt haben. Man kann es sich wie einen Kontoauszug vorstellen: Statt nur den aktuellen Kontostand zu zeigen, zeigt er jede Transaktion, die dazu geführt hat.
Die guten Seiten
Vollständiger Audit-Trail
Das ist das entscheidende Feature. Wenn ein Kunde ein Zahlungsproblem meldet, kann ich jedes Ereignis erneut abspielen und genau sehen, was passiert ist. Kein „Ich weiß nicht, warum das System das gemacht hat” mehr.
Zeitreise-Debugging
Die Möglichkeit, Ereignisse bis zu einem bestimmten Zeitpunkt zu wiederholen, ist beim Debugging unglaublich mächtig. Ich kann Produktionsprobleme lokal reproduzieren, indem ich den Event-Stream erneut abspiele.
Flexibilität bei Projektionen
Brauchen Sie eine neue Sicht auf Ihre Daten? Erstellen Sie einfach eine neue Projektion und spielen Sie die Ereignisse erneut ab. Keine komplexen Datenbank-Migrationen erforderlich.
Die schwierigen Seiten
Komplexität
Event Sourcing bringt erhebliche Komplexität mit sich. Man muss bedenken:
- Event-Versionierung und Schema-Evolution
- Eventuelle Konsistenz
- Wiederaufbau von Projektionen
- Performance des Event Stores
Eventuelle Konsistenz
Ihre Projektionen sind nur eventuell konsistent mit dem Event-Stream. Das kann für Entwickler:innen verwirrend sein, die an sofortige Konsistenz gewöhnt sind.
Debugging ist anders
Wenn etwas schiefgeht, kann man nicht einfach in die Datenbank schauen. Man muss den Event-Stream und die Projektionen verstehen.
Wann Event Sourcing sinnvoll ist
Aus meiner Erfahrung lohnt sich Event Sourcing, wenn:
- Audit-Trail entscheidend ist: Finanzsysteme, Gesundheitswesen, stark regulierte Bereiche
- Komplexe Geschäftslogik: Wenn man nachvollziehen muss, wie man zum aktuellen Zustand gekommen ist
- Mehrere Sichten auf Daten: Wenn unterschiedliche Systemteile unterschiedliche Darstellungen benötigen
Wann Event Sourcing NICHT genutzt werden sollte
Verwenden Sie kein Event Sourcing für:
- Einfache CRUD-Anwendungen: Der Aufwand lohnt sich nicht
- Prototypen oder MVPs: Einfach starten, Komplexität bei Bedarf später hinzufügen
- Wenn das Team noch nicht bereit ist: Event Sourcing erfordert ein Umdenken
Praktische Tipps
Klein anfangen
Event-sourcen Sie nicht Ihr gesamtes System. Beginnen Sie mit einem begrenzten Kontext, in dem die Vorteile klar erkennbar sind.
In Tooling investieren
Bauen Sie gutes Tooling für:
- Das Betrachten von Ereignissen
- Das erneute Abspielen von Ereignissen
- Die Überwachung des Projektions-Lags
- Event-Versionierung
Schema-Evolution einplanen
Ereignisse sind unveränderlich, aber Ihre Geschäftslogik wird sich ändern. Planen Sie von Anfang an Event-Versionierung ein.
Fazit
Event Sourcing ist ein mächtiges Muster, aber keine Wunderwaffe. Nutzen Sie es, wenn die Vorteile (Audit-Trail, Zeitreise, Flexibilität) die Komplexität überwiegen. Für die meisten Anwendungen ist ein klassischer zustandsbasierter Speicher einfacher und ausreichend.
Entscheidend ist, die Trade-offs zu verstehen und auf dieser Grundlage eine fundierte Entscheidung für die eigenen Anforderungen zu treffen.