Publiziert: Zuletzt aktualisiert:

Event-Driven Architecture

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 extremen 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.

graph LR
    A[Webshop] -- Event: Bestellt --> B(Message Broker)
    B --> C[Logistik]
    B --> D[Rechnungswesen]
    B --> E[CRM / Marketing]
    C --> C1[Paketschein]
    D --> D1[PDF Rechnung]
    E --> E1[Follow-up Mail]

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 (z. B. 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 in jeder Millisekunde überall 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 per Design: Da jedes Ereignis aufgezeichnet wird, erhält man automatisch eine lückenlose Historie aller Geschäftsvorgänge (Event Sourcing).

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?

In der Praxis meist nur eine Verzögerung von Millisekunden. Es bedeutet zum Beispiel, dass der Kunde seine Bestätigungsmail erst eine Sekunde nach dem Klick erhält — dafür bricht der Kaufvorgang nie ab, nur weil der Mailserver gerade beschäftigt ist.

Reference Guide

  • Designing Data-Intensive Applications: Martin Kleppmann über die Grundlagen moderner Datenarchitekturen. O'Reilly
  • Building Event-Driven Microservices: Adam Bellemare über EDA in der Praxis. O'Reilly
  • Reactive Manifesto: Die Prinzipien für elastische und resiliente Systeme. reactivemanifesto.org

Verwandte Themen

Offene Punkte