Event-gesteuerte Systeme haben sich im modernen Zahlungsverkehr als dominanter Architekturansatz etabliert – doch zwischen funktionierenden Mustern und kostspieligen Fallstricken liegt oft nur eine Design-Entscheidung. Eine aktuelle Präsentation auf InfoQ zeigt anhand realer Payment-Systeme, was in der Praxis wirklich funktioniert.
Event-Driven Architektur im Banking: Zwischen Effizienzgewinn und operativem Risiko
Warum Event-Driven im Zahlungsverkehr?
Zahlungssysteme stellen besonders hohe Anforderungen an Verfügbarkeit, Konsistenz und Nachvollziehbarkeit. Klassische synchrone Architekturen stoßen bei hohem Transaktionsvolumen schnell an ihre Grenzen: Lange Antwortzeiten, enge Kopplung zwischen Systemkomponenten und fehlende Audit-Trails sind typische Schwachstellen.
Event-Driven Architectures (EDA) versprechen hier Abhilfe, indem Systemkomponenten über asynchrone Ereignisströme kommunizieren statt direkt miteinander. Der Kerngedanke: Jede Transaktion, jede Statusänderung und jede Ausnahme wird als diskretes Ereignis modelliert und über einen Message Broker – etwa Apache Kafka oder RabbitMQ – weitergeleitet. Downstream-Systeme reagieren auf diese Events, ohne dass der ursprüngliche Sender warten oder die Weiterverarbeitung koordinieren muss.
Patterns, die sich in der Praxis bewähren
Outbox Pattern
Um die Konsistenz zwischen Datenbankschreibvorgängen und der Veröffentlichung von Events sicherzustellen, hat sich das Outbox Pattern als zuverlässige Lösung etabliert. Dabei werden Events zunächst atomar in eine separate Datenbanktabelle geschrieben und erst dann vom Message Broker abgeholt.
Das verhindert den klassischen Fehler, bei dem eine Transaktion erfolgreich gespeichert wurde, das zugehörige Event aber nie versendet wurde.
Saga Pattern
Für verteilte Transaktionen – etwa wenn Buchungen über mehrere Systeme hinweg konsistent bleiben müssen – bietet das Saga Pattern eine Alternative zu verteilten Datenbank-Transaktionen (2PC). Jeder Schritt der Transaktion löst einen eigenen Event aus; bei Fehlern werden Kompensationsevents ausgelöst.
- Vorteil: Lose Kopplung zwischen Services
- Nachteil: Erhöhte Komplexität im Fehler-Handling
Event Sourcing
Statt des aktuellen Systemzustands wird die vollständige History aller Events gespeichert. Im Finanzbereich ermöglicht das lückenlose Audit-Trails und vereinfacht regulatorische Anforderungen erheblich. Allerdings steigt der Speicherbedarf, und Abfragen auf den aktuellen Zustand erfordern zusätzliche Read-Modelle (CQRS).
Wo Architekturen scheitern
Mehrere Anti-Patterns führen in der Praxis zu ernsthaften Problemen:
Event-Spaghetti entstehen, wenn zu viele Services auf dieselben Events reagieren, ohne dass klare Ownership-Regeln existieren. Änderungen an einem Event-Schema können dann kaskadierend Dutzende Downstream-Systeme brechen.
Ein weiteres häufiges Problem ist die fehlende Idempotenz: Wenn Message-Broker Ereignisse im Fehlerfall mehrfach zustellen – was in verteilten Systemen als Normalzustand betrachtet werden muss –, können doppelte Buchungen oder Statusinkonsistenzen entstehen.
Jeder Consumer muss so ausgelegt sein, dass er dasselbe Event mehrfach verarbeiten kann, ohne unerwünschte Seiteneffekte zu erzeugen.
Schließlich unterschätzen viele Teams den Aufwand für Observability: Ohne durchgehende Korrelations-IDs, strukturiertes Logging und Event-Tracing ist die Fehlersuche in asynchronen Systemen erheblich aufwändiger als in synchronen Architekturen.
Einordnung für deutsche Unternehmen
Für Banken, Zahlungsdienstleister und FinTechs im deutschsprachigen Raum sind Event-Driven Architekturen aus regulatorischer Sicht besonders relevant. Anforderungen aus PSD2, MiFID II und dem Kreditwesengesetz verlangen nachvollziehbare Transaktionshistorien und klare Datenverantwortlichkeiten.
Event Sourcing und das Outbox Pattern lassen sich direkt als technische Maßnahmen zur Compliance-Umsetzung positionieren. Unternehmen, die heute synchrone Monolithen betreiben, sollten eine Migration jedoch schrittweise planen:
Der Aufbau notwendiger Observability-Infrastruktur und das Schulen von Teams in asynchronem Denken ist erfahrungsgemäß der zeitintensivste Teil solcher Vorhaben.
