Ereignisgesteuerte Architektur hilft, die Kopplung zu reduzieren und die Widerstandsfähigkeit von Systemen zu erhöhen. In der Bankenbranche ist dies aufgrund der Anforderungen an Zuverlässigkeit und Datenkontrolle entscheidend.
Das Problem zeigt sich nicht sofort — bis das System an die Grenzen der Kopplung und der regulatorischen Anforderungen stößt. Im traditionellen Ansatz sind Zahlungssysteme und Transaktionsüberwachung direkt über APIs verbunden. Dies schafft eine starre Abhängigkeit: Ein Ausfall in der Überwachung kann den kritischen Zahlungsfluss beeinträchtigen. Dabei sind die Anforderungen an diese Systeme unterschiedlich: Zahlungen erfordern maximale Verfügbarkeit, während die Überwachung asynchron arbeiten kann. Eine solche Architektur beginnt zu degradieren, wenn die Last zunimmt und die Geschäftslogik komplexer wird.
Die Lösung besteht im Übergang zu einer ereignisgesteuerten Architektur mit asynchronen Ereignissen. In diesem Modell veröffentlicht das Zahlungssystem Ereignisse wie „Zahlung initiiert“ oder „Zahlung verarbeitet“, ohne auf eine Antwort zu warten. Die Transaktionsüberwachung wird zu einem unabhängigen Verbraucher dieser Ereignisse. Dies reduziert die Kopplung und ermöglicht es den Systemen, sich unabhängig weiterzuentwickeln. Der Kompromiss besteht hier im Übergang zu eventual consistency und der Notwendigkeit, das Versionieren von Ereignissen zu verwalten. Es ist auch wichtig, zwischen Befehlen (commands) und Ereignissen (events) klar zu unterscheiden: Erstere erfordern ein Ergebnis, letztere dokumentieren lediglich den Fakt der Zustandsänderung.
Auf der Implementierungsebene spielen die Muster Inbox und Outbox eine Schlüsselrolle. Sie helfen, die Zustellung von Ereignissen zu garantieren und Datenverlust zu verhindern. Die Outbox dokumentiert Ereignisse in der Transaktion mit Zustandsänderung und veröffentlicht sie dann im Broker. Die Inbox ermöglicht es dem Verbraucher, Ereignisse sicher zu verarbeiten und Duplikate zu vermeiden. Dies ist besonders wichtig in regulierten Umgebungen, in denen Datenverlust oder Inkonsistenz inakzeptabel sind. Zusätzlich ist eine durchdachte Namensstrategie für Ereignisse und eine strikte Abgrenzung der Domänen erforderlich, um die Dekomposition des Systems zu erhalten.
Ein zusätzlicher Effekt ist das Auftreten eines unveränderlichen Ereignisprotokolls (immutable log). Im Gegensatz zu klassischen Protokollen spiegelt es das tatsächliche Verhalten des Systems wider und nicht die Neben-Telemetrie. Dies vereinfacht die Nachverfolgung von Prozessen, beispielsweise des Lebenszyklus einer Zahlung: von der Initiierung bis zur Durchführung von Prüfungen. Es ist jedoch zu beachten, dass im ursprünglichen Material keine Metriken für Verbesserungen angegeben sind. Dennoch ermöglicht der Ansatz eine erhöhte Beobachtbarkeit (observability) und vereinfacht die Prüfung, was für Banksysteme entscheidend ist.
Es ist wichtig zu verstehen, dass eine ereignisgesteuerte Architektur nicht zwingend die Verwendung von Event Sourcing erfordert. Diese Ansätze werden oft verwechselt. Event Sourcing ist eine Methode zur Speicherung des Zustands durch eine Sequenz von Ereignissen. Sie ist komplexer in der Umsetzung und erfordert die Wiederherstellung des Zustands durch Replay. In den meisten Fällen reicht es aus, Ereignisse als Integrationsmechanismus zwischen Diensten zu verwenden, ohne das Speicherungsmodell zu komplizieren.
Infolgedessen wird das System widerstandsfähiger gegen Ausfälle und lässt sich besser skalieren. Der Zahlungsfluss ist von sekundären Prozessen isoliert, und neue Verbraucher können sich ohne Änderungen an bestehenden Diensten mit den Ereignissen verbinden. Dies ist eine pragmatische Wahl für Systeme mit hoher Last (highload) und strengen Anforderungen an die Zuverlässigkeit.