Eine Event-driven Architecture, kurz EDA, ist eine Softwarearchitektur, bei der Systeme auf Ereignisse reagieren, anstatt sich permanent gegenseitig abzufragen. Ein Ereignis beschreibt dabei eine relevante Zustandsänderung, beispielsweise „Bestellung erstellt“, „Zahlung abgeschlossen“, „Produkt geändert“ oder „Versand gestartet“.
Besonders bei E-Commerce, Middleware, Microservices und komplexen Systemlandschaften ermöglicht eine ereignisgesteuerte Architektur flexible und weitgehend entkoppelte Integrationen. Shopware, ERP, CRM, Logistik oder Marketing-Systeme können dadurch auf Veränderungen reagieren, ohne direkt voneinander abhängig zu sein.
Wie funktioniert eine Event-driven Architecture?
Eine ereignisgesteuerte Architektur besteht vereinfacht aus drei Komponenten:
Event Producer → Event Broker oder Kanal → Event Consumer
Der Producer erzeugt ein Ereignis.
Der Broker oder Nachrichtenkanal verteilt es.
Der Consumer reagiert darauf.
Ein Beispiel aus dem E-Commerce:
Shopware → Bestellung erstellt → Event Broker → ERP, CRM und Logistik
Shopware muss dabei nicht zwingend wissen, welche Systeme das Ereignis später verwenden. Es veröffentlicht lediglich die Information, dass etwas passiert ist.
Was ist ein Event?
Ein Event beschreibt eine bereits eingetretene Änderung.
Typische Events sind:
order.createdpayment.completedproduct.updatedcustomer.registeredshipment.created
Ein Event sollte fachlich möglichst eindeutig formuliert werden.
Statt:
„Bestellung bearbeiten“
ist:
„Bestellung wurde erstellt“
besser geeignet.
Das Event beschreibt nämlich einen Zustand und nicht die Anweisung, was anschließend passieren soll.
Producer, Broker und Consumer
Event Producer
Der Producer erzeugt das Ereignis.
Beispiele:
- Shopware
- ERP
- CRM
- Zahlungsdienstleister
Event Broker
Der Event Broker nimmt Ereignisse entgegen und verteilt sie an interessierte Systeme.
Bekannte Technologien dafür sind beispielsweise:
- Apache Kafka
- RabbitMQ
- Amazon EventBridge
- Azure Event Grid
Bei kleineren Integrationen kann auch eine Middleware diese Rolle übernehmen.
Event Consumer
Ein Consumer reagiert auf das Ereignis.
Bei einer neuen Bestellung könnten beispielsweise mehrere Systeme reagieren:
ERP: Auftrag erstellen
CRM: Kundenhistorie aktualisieren
Logistik: Versandprozess vorbereiten
Data Warehouse: Umsatz erfassen
Beispiel mit Shopware 6
Ein Kunde bestellt im Shopware-Shop.
Shopware erzeugt das Ereignis:
Bestellung wurde abgeschlossen
Anschließend kann folgende Verarbeitung stattfinden:
- Shopware sendet einen Webhook.
- Middleware empfängt das Ereignis.
- Ereignis wird in einer Queue gespeichert.
- ERP erstellt den Auftrag.
- CRM aktualisiert den Kunden.
- Logistik erhält die Versandinformationen.
Shopware unterstützt bei Apps ereignisbasierte Integrationen über Webhooks. Apps können sich beispielsweise für Ereignisse wie checkout.order.placed oder Änderungen an Produkten registrieren.
Event-driven Architecture und Webhooks
Webhooks sind eine einfache Form ereignisbasierter Kommunikation.
Ein Ereignis tritt ein:
Bestellung erstellt
Danach wird automatisch eine HTTP-Anfrage an ein externes System gesendet.
Eine vollständige Event-driven Architecture geht jedoch häufig weiter. Zwischen Producer und Consumer befindet sich oftmals ein Broker oder eine Queue.
Dadurch muss das empfangende System nicht exakt in diesem Moment verfügbar sein.
Event-driven Architecture und klassische API
Eine klassische API-Integration funktioniert häufig nach dem Request-Response-Prinzip.
ERP → API → Shopware
Das ERP fragt aktiv:
„Gibt es neue Bestellungen?“
Bei einer Event-driven Architecture informiert Shopware dagegen:
„Eine neue Bestellung wurde erstellt.“
| Klassische API-Abfrage | Event-driven Architecture |
|---|---|
| System fragt aktiv nach | System reagiert auf Ereignisse |
| häufig Polling | ereignisgesteuert |
| stärkere direkte Kopplung | stärkere Entkopplung möglich |
| einfach für kleine Prozesse | gut für komplexe Integrationen |
| unmittelbare Antwort | häufig asynchron |
Beide Ansätze werden in modernen Systemen häufig kombiniert.
Vorteile einer Event-driven Architecture
Geringere Kopplung
Producer müssen nicht alle empfangenden Systeme kennen.
Gute Skalierbarkeit
Neue Consumer können ergänzt werden, ohne den Producer grundsätzlich verändern zu müssen.
Schnelle Reaktion
Ereignisse können nahezu in Echtzeit verarbeitet werden.
Höhere Ausfallsicherheit
Mit Queues und persistenten Nachrichten können Ereignisse später weiterverarbeitet werden, wenn ein Zielsystem vorübergehend nicht verfügbar ist.
Flexible Erweiterbarkeit
Aus einem Ereignis können mehrere unabhängige Prozesse entstehen.
Grenzen und Herausforderungen
Event-driven Architecture erhöht gleichzeitig die technische Komplexität.
Typische Herausforderungen sind:
- doppelte Events
- falsche Reihenfolge
- verzögerte Verarbeitung
- Fehler in einzelnen Consumern
- schwerere Fehlersuche
- unterschiedliche Event-Versionen
- eventual consistency
Besonders wichtig sind deshalb Logging, Monitoring, Idempotenz und Retry-Mechanismen.
Eventual Consistency
Bei asynchronen Systemen sind nicht immer alle Systeme exakt zur gleichen Zeit auf demselben Datenstand.
Eine Bestellung kann beispielsweise bereits in Shopware vorhanden sein, während das CRM sie erst zwei Sekunden später verarbeitet.
Dieses Prinzip wird als Eventual Consistency bezeichnet.
Die Systeme werden also nicht zwingend sofort, sondern innerhalb kurzer Zeit konsistent.
Für Prozesse, die zwingend eine sofortige und vollständig konsistente Antwort benötigen, ist eine rein ereignisgesteuerte Architektur deshalb nicht immer geeignet.
Event-driven Architecture und Idempotenz
Events können mehrfach zugestellt werden.
Ein Consumer muss deshalb verhindern, dass dasselbe Ereignis mehrfach dieselbe Geschäftsaktion ausführt.
Beispiel:
Order Event wird zweimal geliefert
Das ERP darf trotzdem nur einen Auftrag erstellen.
Dafür können Event-ID, externe Referenz oder Idempotency Key gespeichert werden.
Wann ist EDA sinnvoll?
Eine Event-driven Architecture eignet sich besonders, wenn:
- mehrere Systeme auf dieselben Ereignisse reagieren
- Prozesse nahezu in Echtzeit ablaufen sollen
- Systeme unabhängig voneinander skalieren sollen
- viele Integrationen vorhanden sind
- Ausfälle einzelner Systeme abgefangen werden müssen
Für eine einfache Verbindung zwischen zwei Systemen kann eine klassische API dagegen häufig einfacher sein.
FAQ zu Event-driven Architecture
Ist ein Webhook bereits eine Event-driven Architecture?
Ein Webhook ist ein wichtiges Werkzeug dafür, bildet aber allein noch nicht zwingend eine vollständige EDA.
Braucht man immer Kafka oder RabbitMQ?
Nein. Kleine Systeme können mit Webhooks oder einfachen Queues beginnen. Ein Event Broker wird vor allem bei steigender Komplexität interessant.
Sind Events und Webhooks dasselbe?
Nein. Das Event beschreibt das Ereignis. Ein Webhook ist eine mögliche technische Methode, dieses Ereignis an ein anderes System zu übertragen.
Was passiert, wenn ein Consumer ausfällt?
Bei einer robusten Architektur wird das Event gespeichert und später erneut verarbeitet.
Ist EDA für Shopware geeignet?
Ja. Besonders bei ERP-, CRM-, Logistik- und App-Integrationen können Webhooks und ereignisbasierte Prozesse sinnvoll eingesetzt werden.
Weiterführende Wiki-Einträge
Passende Themen sind:
- Webhook
- API-Schnittstelle
- API-Synchronisation
- Idempotenz
- Single Source of Truth
- Middleware
- Shopware 6 API
- Shopware 6 Flow Builder
Passende CUTVERT-Leistungen
Passende Leistungen von CUTVERT sind insbesondere:
Event-driven Architecture: Ereignisgesteuerte Systemintegration einfach erklärt
