Event-gesteuerte Architektur in Banksystemen bietet Skalierung und Isolation, bringt jedoch neue Klassen von Fehlern mit sich. Wir analysieren, wo sie funktioniert und wo sie scheitert.
Das Problem zeigt sich nicht sofort — bis zu dem Moment, an dem synchrone Ketten an abhängigen Diensten und regulatorischen Anforderungen scheitern. In Zahlungsströmen ist dies kritisch: externe Anti-Betrugsdienste, Transaktionsüberwachung und Benachrichtigungen konkurrieren um Platz im kritischen Pfad. Jede Verschlechterung erhöht die Latenz und verringert die Zuverlässigkeit. Gleichzeitig wächst die Kopplung: Änderungen in einem Dienst erfordern Koordination mit anderen. In diesem Stadium „maskieren“ Teams oft Befehle als Ereignisse, was die starre Kopplung beibehält und keine Vorteile der event-gesteuerten Architektur bietet.
Die Entscheidung für eine event-gesteuerte Architektur ist der Versuch, diesen Knoten zu durchtrennen. Systeme tauschen Fakten (Ereignisse) aus, nicht Absichten (Befehle). Dies verringert die Kopplung und ermöglicht die asynchrone Verarbeitung von Nebenaufgaben. Der Kompromiss ist offensichtlich: es entsteht eventual consistency und das Betriebsmodell wird komplizierter. Die Frage des Datenvolumens in einem Ereignis ist ebenfalls ein Kompromiss. Die Praxis zeigt, dass ein Ereignis nur Daten tragen sollte, die direkt mit der Zustandsänderung zusammenhängen. Dies vereinfacht die Evolution von Verträgen und verringert die versteckte Kopplung. Es ist wichtig, dies nicht mit Event Sourcing zu verwechseln: Die Speicherung des Zustands als Sequenz von Ereignissen ist eine separate Lösung mit hohen Implementierungskosten.
Die Implementierung stößt auf die Disziplin der Verträge und grundlegende Muster der Zuverlässigkeit. Der Produzent veröffentlicht Ereignisse in die Eventing-Plattform, ohne die Verbraucher zu kennen. Die Verbraucher abonnieren und verarbeiten unabhängig, was Fan-out und Fehlerisolierung ermöglicht. Im banklichen Kontext ermöglicht dies, die Transaktionsüberwachung außerhalb des kritischen Zahlungswegs zu verlagern. Aber Zuverlässigkeit entsteht nicht „von selbst“. Das minimale Set sind Outbox- und Inbox-Muster.
- Die Outbox erfasst die Zustandsänderung und das Ereignis in einer Transaktion, um den Verlust von Ereignissen zu verhindern. Die Veröffentlichung erfolgt durch einen asynchronen Dispatcher.
- Die Inbox auf der Verbraucherseite registriert das Ereignis vor der Geschäftslogik und ignoriert Duplikate, was bei at-least-once Lieferung kritisch ist.
Ein separater Risikobereich ist die Grenze zwischen Teams und „versteckten Lösungen“. Ohne frühzeitige Abstimmung von Event-Verträgen und Standards fragmentiert die Plattform schnell. Inkompatible Schemata, unterschiedliche semantische Bedeutungen von Ereignissen und steigende Betriebskosten entstehen. Die Praxis der „paved paths“ und vorgefertigten Servicetemplates verringert die Variabilität und beschleunigt das Onboarding. Aber Werkzeuge ersetzen kein Training: Der Übergang zu asynchronem Denken erfordert Zeit. In realen Teams kann der Weg zur Produktivität nach der Implementierung von event-gesteuerten Architekturen und (insbesondere) Event Sourcing Monate in Anspruch nehmen. Die häufigsten Fehler sind die Unterschätzung von Retries, Idempotenz und der Verarbeitung von Teilschäden.
Was sich am Ende ändert. Erstens entsteht eine natürliche Trennung der Verantwortlichkeiten: Die Zahlung wird unabhängig von der Überwachung und den Benachrichtigungen ausgeführt. Dies erhöht die Fehlertoleranz gegenüber externen Abhängigkeiten. Zweitens bilden Ereignisse ein unveränderliches Aktivitätsprotokoll (activity log), das die Nachverfolgbarkeit und Prüfung vereinfacht. Drittens ermöglicht der Fan-out das Hinzufügen neuer Funktionen, ohne den Kern zu ändern — durch Abonnieren bestehender Ereignisse. Dabei hängen die Verbesserungsmetriken vom spezifischen System ab und sind in den Ausgangsdaten nicht aufgeführt.
Aber der Preis ist ein ständiges Management von Verträgen und Versionen. Ereignisse leben lange und können neu gespielt werden. Das Löschen oder Ändern von Feldern bricht Verbraucher. Eine strenge Evolution der Schemata und Abwärtskompatibilität ist erforderlich. Ein weiterer Aspekt ist die Fehlertoleranz auf Plattformebene: Backoff-Strategien, Dead-Letter-Warteschlangen und Beobachtbarkeit (observability), um zu verstehen, wo Ereignisse „stecken geblieben“ sind.
Das Fazit — es ist keine „universelle Antwort“, sondern eine pragmatische Wahl. Event-gesteuerte Architektur in Banksystemen funktioniert gut dort, wo es klare Grenzen und asynchrone Nebenprozesse gibt. Sie bietet Skalierung und Flexibilität, erfordert jedoch eine reife Plattform, Disziplin bei den Verträgen und die Vorbereitung der Teams. Ohne dies werden die Vorteile schnell neutralisiert, während die Komplexität bleibt.