Die Einführung von Event-Sourcing

Kund:innen verfügen oft über umfangreiche Erfahrungen und Kenntnisse, auf denen ihre Projekte aufbauen und die auch die meisten ihrer Entscheidungen beeinflussen. Lösungsvorschläge, die von solchen Traditionen abweichen, stossen oft auf nachvollziehbare Skepsis. In solchen Fällen ist entscheidend, klar zu vermitteln, warum es sich lohnt, andere Wege zur Problemlösung gegenüber den bewährten vorzuziehen. Dieser Artikel schildert einen solchen Fall, bei dem die Lösung eines Problems es erforderlich machte, den Status quo etablierter Praktiken in Frage zu stellen. Es musste sorgfältig darauf geachtet werden, die Grenzen der gegenwärtigen Implementierungen zu erklären und sicherzustellen, dass alle Anwendungsfälle, die diesem Kunden wichtig waren, auch mit einem anderen, neuen Ansatz möglich wären.

Die Herausforderung

Lassen Sie uns kurz die Herausforderung definieren und dann nach einer möglichen Lösung suchen. Der Kunde wollte eine Software namens DAN entwickeln, mit der vorrangigen Funktion, die Zusammenführung von Daten aus mehreren Datenquellen zu berechnen. Jede Datenquelle liefert im Laufe der Zeit inkrementelle Informationen über Entitäten, und DAN hat die Aufgabe, diese Fragmente zu einer vollständigen Darstellung jeder Entität zusammenzusetzen.

Alle von DAN verarbeiteten Informationen werden über einen firmeneigenen Message-Bus übermittelt, wodurch DAN mit den typischen Herausforderungen nachrichtenbasierter Architekturen konfrontiert ist, wie z.B. Lieferungen in falscher Reihenfolge, fehlende oder wiederholte Lieferungen, usw.

Ursprüngliche Lösung und deren Zuverlässigkeit

Aufgrund des Hintergrunds und des Fachwissens des Kunden basierte die erste Implementierung von DAN zunächst auf einem relationalen Modell mit PostgreSQL als Datenbank. Dieses relationale Modell wird mit Hilfe von Tabellen normalisiert, die mit eigens hierfür zusammengestellten bi-temporalen Funktionen erweitert werden. Die Datenbank funktioniert wie ein «Append-Only»-Protokoll: Nach Eingang einer Nachricht wird das letzte Teilergebnis dupliziert und das Duplikat mit den Informationen aus der eingegangenen Nachricht kombiniert. Alle Zeilen des vorherigen Teilergebnisses bleiben unangetastet und werden lediglich als veraltet markiert, so dass zu einem bestimmten Zeitpunkt nur ein gültiges Teilergebnis vorliegt. Die Speicherung all dieser Teilergebnisse ist für DAN von entscheidender Bedeutung, um im Fall eines Missbrauchs eine Kontrollfunktion zu gewährleisten.

Oberflächlich betrachtet ist dieser Ansatz natürlich legitim und bietet alle Kernfunktionen, die der Kunde haben möchte. Warum also diese Lösung in Frage stellen?

Was, wenn eine versäumte Lieferung erst später nachgereicht wird?

Eine verpasste Lieferung zu einem späteren Zeitpunkt zu erhalten, bedeutet tatsächlich eine Lieferung in falscher Reihenfolge. Ein relationales Modell macht diese Lieferungen zu einer Herausforderung: Wir erhalten damit Teilergebnisse, die möglicherweise mit einer falschen Nachrichtensequenz erstellt wurden.

Dass dieses Problem auftritt, kann nicht verhindert werden: Das würde eine fortgeschrittene Kenntnis der gesamten Nachrichtensequenz erfordern, die per Definition unendlich ist (oder so lang wie die Lebensspanne eines Entwicklers).

Sich von so einem Szenario wieder zu erholen, ist nicht einfach. Hierfür müssen wir alle fehlerhaften Teilergebnisse, die zuvor berechnet wurden, wiederherstellen, indem wir Nachrichten verwenden, die aktueller sind als die zuvor eingegangene Nachricht. Dazu verwerfen wir alle fehlerhaften Teilergebnisse und werten dann in logischer Reihenfolge alle Nachrichten, die aus den verworfenen Teilergebnissen entstanden sind, erneut aus. Diese Lösung setzt voraus, dass alle an DAN übermittelten Nachrichten gespeichert werden, da es ohne die Ursprungsnachricht unmöglich wäre, ein Teilergebnis neu zu berechnen. Tatsächlich klingt das vertraut.

Was hat das mit Event-Sourcing zu tun?

Die Idee des Event-Sourcing besteht darin, Änderungen am Anwendungsstatus als eine Abfolge von Ereignissen zu erfassen und dann die gesamte Abfolge bei Bedarf wieder abzuspielen, um den Status neu zu erstellen. Event-Sourcing hat eine interessante Eigenschaft: die eventuelle Konsistenz. Dieses Systemmerkmal gewährleistet, dass man beim Auslesen von Daten, an denen keine neuen Änderungen vorgenommen wurden, im Laufe der Zeit wieder den zuletzt aktualisierten Wert erhält.

Die eventuelle Konsistenz vereinfacht den Umgang mit Lieferungen, die nicht in der richtigen Reihenfolge erfolgen. Die Ergebnisse werden nebenher dynamisch berechnet. Wenn also neue Nachrichten eintreffen, werden daher bei jeder nachfolgenden Ergebnisberechnung implizit alle neuen und alten Meldungen in logischer Reihenfolge berücksichtigt.

Event-Sourcing vorschlagen

Verständlicherweise stiess der Vorschlag, Event-Sourcing einem relationalen Modell vorzuziehen, beim Kunden auf plausible Skepsis. Schliesslich stellen wir eine bewährte und durchweg etablierte Lösung mit einem völlig anderen Ansatz in Frage - einem Ansatz, bei dem nicht einmal der tatsächliche Anwendungsstatus gespeichert wird, was die Erstellung von Berichten erschwert und eine freie Abfrage der Anwendungsdaten nicht zulässt. Diese Merkmale sind aber keine harten Anforderungen, sondern de facto Standardfunktionen, die der Kunde einfach wertschätzt.

In solchen Situationen ist es wichtig, alle technischen Schwierigkeiten, die mit einer Lösung einhergehen, klar zu kommunizieren. Der hierfür gewählte Ansatz bestand nun darin, ein Beispiel für dieses Problem zu schildern und dann eine Simulation zu erstellen, die das demonstriert – in diesem Fall durch die Nachahmung von Datenbanktabellen mit Microsoft Excel. Sobald das Problem verstanden ist, wird eine weitere Simulation verwendet, um zu zeigen, wie Event-Sourcing das Problem automatisch löst.

Event-Sourcing diskutieren und vergleichen

Ein weiterer kniffliger Schritt war nötig, um sicherzustellen, dass der Kunde schliesslich auf Event-Sourcing vertauen würde, und zwar durch einen ehrlichen Vergleich mit der vorherigen Lösung. Dabei muss man auch unbedingt im Auge haben, dass man leicht als „Quacksalber“ erscheinen kann, der lediglich versucht, dem Kunden ein paar zusätzliche Stunden zu berechnen.

Für dieses Projekt war ein Dokument mit einer Beschreibung von Event-Sourcing und relationalen Modellen sehr nützlich. Es zeigte einen Vergleich und wies auf fehlende Funktionen hin, die die Akzeptanz möglicherweise gefährden könnten. Wichtig ist, dass wir niemals eine Lösung als die endgültige Lösung darstellen, sondern neutral Daten und Informationen bereitstellen, um Diskussionen und Feedback anzuregen. Die Zeit, die für die Beantwortung von Fragen und die Klärung von Zweifeln aufgewendet wird, ist eine Investition in Vertrauen und unterstützt die Lösung.

Akzeptanz von Event-Sourcing

Zusammenfassend lässt sich sagen, dass wir die Tatsache akzeptieren müssen, dass die Richtlinien eines Kunden eine bestimmte Lösung manchmal nicht zulassen. Dies mag wie eine willkürliche Auflage klingen (ist es ja auch), aber grundlegend müssen wir die technologische und organisatorische Kultur dahinter respektieren.

Zum Glück war das in diesem Fall nicht nötig. Event-Sourcing konnte unserem Kunden einen einfacheren und leichter zu pflegenden Mechanismus bieten, um den Überblick über alle Informationen in DAN zu behalten. In der Tat waren zusätzliche Entwicklungsressourcen erforderlich, um eine traditionell abfragbare Berichtsdatenbank zu erstellen. Da dies aber nicht in Widerspruch zu den Kernanforderungen steht, wurde es als vertretbarer Kompromiss angesehen.

Abschliessend betrachtet hat sich die Beratung des Kunden durch objektive Darstellung der Fakten (einschliesslich derer, die nicht vorteilhaft sind) und durch transparentes Aufzeigen der Vor- und Nachteile als erfolgreiche Strategie zur Vertrauensbildung und zur Innovationsförderung erwiesen. Ein solches Umfeld mit einer Atmoshäre von echter Zusammenarbeit ist ideal, um Lösungen zu schaffen und vorzuschlagen, die die Entwicklung vereinfachen, Kosten senken und das Selbstvertrauen des Entwicklers stärken.