Event-Driven Architecture (EDA)
Einleitung
Event-Driven Architecture (EDA) ist ein Architekturstil, bei dem Zustandsänderungen als Ereignisse modelliert und über ein System verteilt werden.
Nicht Requests stehen im Zentrum,
sondern Events als Fakten über etwas, das bereits passiert ist.
EDA verschiebt Kopplung:
- weg von synchronen Abhängigkeiten
- hin zu Daten- und Semantikverträgen
EDA ist kein Messaging-Detail.
Es ist ein Integrations- und Denkmodell.
Grundidee
Services reagieren auf Zustandsänderungen – nicht auf direkte Aufrufe.
Ein Event beschreibt:
- etwas ist passiert
- unveränderlich
- fachlich bedeutend
- vergangenheitsorientiert
Beispiel:
OrderCreatedPaymentFailedUserRegistered
Nicht:
CreateOrderDoPayment
Prinzipdarstellung
Kernaussage:
- Producer kennt Consumer nicht
- Consumer können beliebig ergänzt werden
- Entkopplung erfolgt zeitlich und technisch
Architekturprinzipien
1️⃣ Events sind Fakten
- unveränderlich
- nicht rückwirkend modifizierbar
- keine Kommandos
- keine RPC-Requests
2️⃣ Asynchronität ist Default
EDA ist:
- nicht-blockierend
- zeitlich entkoppelt
- resilient gegen Teilausfälle
Das System ist nicht sofort konsistent, sondern eventual consistent.
3️⃣ Lose Laufzeitkopplung – starke Semantikkopplung
Producer kennen Consumer nicht. Aber alle müssen das Event verstehen.
Deshalb ist Schema-Governance kritisch.
Varianten von EDA
Event Notification
Event enthält nur Identifier:
OrderCreated { orderId }
Consumer lädt Daten separat.
Vorteil: kleine Events Nachteil: zusätzliche Abhängigkeiten
Event-Carried State Transfer
Event enthält relevante Daten:
OrderCreated { orderId, amount, items }
Vorteil: echte Entkopplung Nachteil: Versionierungsaufwand
Event Sourcing
- Zustand wird ausschließlich aus Event-Historie rekonstruiert
- Events sind System-of-Record
- Hohe Komplexität, hohe Nachvollziehbarkeit
Nicht jede EDA ist Event Sourcing.
EDA in Microservices
EDA eignet sich besonders für:
- fachliche Domänenentkopplung
- Integrationsszenarien
- Nebenwirkungen
- reaktive Workflows
- Erweiterbarkeit
Aber:
EDA ersetzt nicht saubere Domänenschnitte.
EDA in Microfrontends
Auch im Frontend:
- UI-Events als Integrationsmechanik
- lose Kopplung zwischen Teilanwendungen
- Shared State über Event Bus
Risiko: Event-Chaos ohne klare Semantik.
Vorteile
- Zeitliche Entkopplung
- Hohe Skalierbarkeit
- Erweiterbarkeit durch neue Consumer
- Reduzierte Cascading Failures
- Natürliche Auditierbarkeit
Nachteile / Risiken
1️⃣ Debugging-Komplexität
- Verteilte Event-Flows
- Asynchrone Ausführung
- Fehlersuche über mehrere Systeme
Observability ist Pflicht.
2️⃣ Event-Governance
- Schema-Versionierung
- Breaking Changes
- Naming-Konventionen
- Ownership-Regeln
Ohne Governance entsteht Event-Spaghetti.
3️⃣ Eventual Consistency
Nicht geeignet für:
- harte synchrone Transaktionen
- sofortige globale Konsistenzanforderungen
4️⃣ Event-Explosion
Zu viele Events führen zu:
- unklarer Semantik
- unkontrollierter Kopplung
- versteckter Geschäftslogik
Synchron vs. Event-Driven
EDA ersetzt nicht jede synchrone Kommunikation.
Leitfrage:
- Muss der Aufrufer sofort eine Antwort erhalten?
- Oder reicht Reaktion auf Zustandsänderung?
Reife Systeme kombinieren beide.
Organisatorische Implikationen
EDA erfordert:
- klare Event-Owner
- Schema-Registry
- Versionierungsstrategie
- Observability-Standards
- Idempotente Consumer
EDA ohne Ownership führt zu:
verteiltem Chaos statt Entkopplung.
Eignung 2026
Geeignet bei:
- Großen Integrationslandschaften
- Hoher Erweiterungsdynamik
- Streaming-/Realtime-Szenarien
- Microservice-Ökosystemen
Weniger geeignet bei:
- Kleinen, überschaubaren Systemen
- Strikten ACID-Anforderungen
- Fehlender Event-Governance
Fazit
EDA ist kein Messaging-Tool. Es ist ein Denkmodell.
Es verschiebt Komplexität:
- von Laufzeitkopplung
- zu Daten- und Semantikkopplung
Richtig eingesetzt erhöht EDA:
- Skalierbarkeit
- Erweiterbarkeit
- Resilienz
Falsch eingesetzt erzeugt es:
- Event-Chaos
- Debugging-Hölle
- Governance-Overhead