Publiziert:

Event-Driven Architecture

Entkopplung macht Systeme belastbar

Event-Driven Architecture (EDA) ist ein Paradigma, bei dem der Fluss der Applikation durch Ereignisse (Events) gesteuert wird, zum Beispiel "Kunde hat bestellt" oder "Lagerbestand niedrig". Statt dass Systeme aufeinander warten (synchron), reagieren sie zeitversetzt auf diese Ereignisse (asynchron).

Dies führt zu einer starken Entkopplung der Systeme: Der Webshop muss nicht wissen, wie das Versandsystem funktioniert. Er veröffentlicht nur das Event "Bestellung abgeschlossen" und überlässt den Rest der Infrastruktur. Wie sich solche ereignisgetriebenen Datenflüsse zu kontrollierten, automatisierten Abläufen über Systemgrenzen hinweg verbinden, behandelt die Workflow-Automation und Datenflüsse.

sequenceDiagram
    participant Shop as Webshop
    participant Broker as Message Broker
    participant Logistik
    participant Rechnung as Rechnungswesen
    participant CRM as CRM / Marketing
    Shop->>Broker: Event Bestellt publizieren
    Broker-->>Logistik: Bestellung ausliefern
    Broker-->>Rechnung: Rechnung erzeugen
    Broker-->>CRM: Follow-up vorbereiten
    Logistik-->>Broker: Paketschein erstellt
    Rechnung-->>Broker: PDF Rechnung erstellt
    CRM-->>Broker: Follow-up Mail geplant

Anti-Patterns: Das Kartenhaus-Syndrom

In synchronen Architekturen (Request-Response) führt der Ausfall eines einzelnen kleinen Teilsystems oft zum Stillstand des gesamten Prozesses. Wenn das System zur Rechnungsstellung langsam ist, bricht der Checkout im Webshop ab, da er auf die Antwort wartet. Dies begrenzt die Skalierbarkeit und macht das System anfällig für Lastspitzen.

Die reaktive Organisation

  1. Message Broker / Event Bus: Einsatz von spezialisierter Middleware (zum Beispiel RabbitMQ, Kafka oder NATS), die Events sicher speichert und verteilt.
  2. Pub/Sub Pattern: Sender (Publisher) und Empfänger (Subscriber) kennen sich nicht. Dies erlaubt es, jederzeit neue Systeme anzudocken, ohne den Bestandscode zu ändern.
  3. Eventual Consistency: Akzeptanz, dass Daten nicht überall zu jedem Zeitpunkt exakt gleich sein müssen, solange sie "schliesslich" (eventually) konsistent werden.
  4. Resilienz durch Pufferung: Ist ein Empfänger-System offline, werden die Events im Broker zwischengespeichert und später verarbeitet, sobald das System wieder online ist.
  5. Audit-Log als Option: EDA bedeutet nicht automatisch eine dauerhafte Aufzeichnung aller Ereignisse. Wird Event Sourcing bewusst umgesetzt (ein eigenes Muster, bei dem alle Zustandsänderungen als Events gespeichert werden), können die Events zum System of Record und damit zur lückenlosen Historie der Geschäftsvorgänge werden.

Der Vorteil: Hohe Skalierbarkeit

Events können massenhaft parallel verarbeitet werden. Lastspitzen im Frontend werden durch den Event-Bus geglättet, sodass die Backend-Systeme stabil in ihrem eigenen Tempo weiterarbeiten können.

FAQ

Ist EDA nicht viel schwerer zu debuggen als synchrone Calls?

Es erfordert andere Werkzeuge (Distributed Tracing). Aber die Fähigkeit, Events erneut abzuspielen (Replay), macht es in komplexen Szenarien sogar einfacher, Fehler zu finden und zu beheben.

Was bedeutet Eventual Consistency für unser Business?

Die Verzögerung ist systemspezifisch und hängt von Topologie, Fehlerfällen, Warteschlangen, Konfliktauflösung, Backpressure, Retry-Strategie und Geschäftsprozess ab. Eventual Consistency garantiert keine feste Millisekunden-Grenze; die erwartete Verzögerung gehört als SLO definiert und gemessen. In vielen Fällen erhält der Kunde die Bestätigungsmail kurz nach dem Klick, und der Kaufvorgang bricht nicht ab, nur weil der Mailserver gerade beschäftigt ist.

Referenzen