Was ist Event-Driven Architecture?
Event-Driven Architecture ist ein Ansatz zur Gestaltung von Anwendungen, bei dem einzelne Komponenten über Events (Ereignisse) miteinander kommunizieren.
Ein Event informiert das System darüber, dass etwas passiert ist. Zum Beispiel:
- eine Bestellung wurde erstellt,
- eine Zahlung wurde abgeschlossen,
- ein Benutzer hat sich registriert,
- der Status einer Bestellung wurde geändert,
- ein Produkt wurde wieder auf Lager genommen.
Nehmen wir eine E-Commerce-Anwendung als Beispiel. Wenn ein Kunde eine Bestellung aufgibt, erstellt das System ein Event:
OrderCreated
Dieses Event kann anschließend vom Payment Service, dem Lagerverwaltungssystem und dem Notification Service verarbeitet werden. Der Service, der die Bestellung erstellt hat, muss diese Komponenten nicht direkt aufrufen.
Request-Response vs. Event-Driven
Beim klassischen Request-Response-Modell könnte die Kommunikation beispielsweise so aussehen:
Order Service → Payment Service → Warehouse Service → Notification Service
Jeder Service wartet auf die Antwort des vorherigen. Wenn ein Service langsam oder nicht verfügbar ist, kann dies die gesamte Anfrage beeinflussen.
Bei einem eventbasierten Modell kann der Ablauf hingegen so aussehen:
Order Service → OrderCreated
Danach:
OrderCreated → Payment Service
OrderCreated → Warehouse Service
OrderCreated → Notification Service
Der Unterschied besteht darin, dass ein Service lediglich mitteilt, was passiert ist. Die anderen Komponenten entscheiden selbst, ob und wie sie auf dieses Event reagieren.
Das Ergebnis ist eine lockerere Kopplung zwischen den einzelnen Teilen des Systems.
Message Queues und Event Broker
In größeren Anwendungen werden Events häufig nicht direkt zwischen den einzelnen Services übertragen. Stattdessen kann ein Message Broker Nachrichten empfangen und zwischen den Komponenten verteilen.
Vereinfacht dargestellt:
Producer → Message Broker → Consumers
Ein Broker kann beispielsweise die Zustellung von Nachrichten, deren temporäre Speicherung, Wiederholungsversuche und die Verteilung von Nachrichten an mehrere Consumer übernehmen.
Zwei Technologien, die häufig in diesem Zusammenhang eingesetzt werden, sind RabbitMQ und Apache Kafka.
RabbitMQ vs. Kafka
RabbitMQ ist ein Message Broker, der sich besonders für die klassische Verarbeitung von Nachrichten, Queues und Background Tasks eignet. Er kann beispielsweise bei der Verarbeitung von Bestellungen oder der Generierung von Dokumenten im Hintergrund eingesetzt werden.
Kafka ist eine verteilte Event-Streaming-Plattform, die für die Verarbeitung großer Mengen von Events entwickelt wurde. Sie eignet sich insbesondere für Szenarien, in denen große Datenmengen verarbeitet werden und mehrere Systeme mit demselben Event-Stream arbeiten sollen.
Es gibt keine einfache Antwort darauf, welche Technologie „besser“ ist. Die richtige Wahl hängt vom konkreten Problem, dem Datenvolumen, den Anforderungen an die Verarbeitung und der geplanten Skalierungsstrategie ab.
Wie sieht ein eventbasierter Bestellprozess aus?
Nehmen wir eine einfache E-Commerce-Anwendung:
- Erstellung der Bestellung
Der Order Service erstellt die Bestellung und veröffentlicht OrderCreated. - Zahlung
Der Payment Service verarbeitet das Event und erstellt nach erfolgreicher Zahlung PaymentCompleted. - Lagerbestand
Der Warehouse Service reagiert auf das Event und aktualisiert den Lagerbestand. - Benachrichtigung
Der Notification Service sendet dem Kunden eine Bestellbestätigung.
Der daraus entstehende Ablauf ist:
OrderCreated → PaymentCompleted → InventoryUpdated → NotificationSent
Jeder Service übernimmt seine eigene Aufgabe, ohne eng von den anderen Services abhängig zu sein.
Was passiert, wenn ein Service ausfällt?
Ein wichtiger Vorteil einer eventbasierten Architektur ist die Möglichkeit der asynchronen Verarbeitung.
Wenn der Notification Service beispielsweise vorübergehend nicht verfügbar ist, kann ein Event im Message Broker gespeichert und verarbeitet werden, sobald der Service wieder verfügbar ist.
Dieser Ansatz bringt jedoch auch neue Herausforderungen mit sich. Entwickler müssen beispielsweise doppelte Events, Retry-Mechanismen, die Reihenfolge von Nachrichten, Monitoring und Fehler bei der Verarbeitung berücksichtigen.
Wann lohnt sich Event-Driven Architecture?
EDA kann insbesondere für folgende Systeme sinnvoll sein:
- E-Commerce-Plattformen,
- Zahlungs- und Logistiksysteme,
- IoT-Anwendungen,
- Analytics-Plattformen,
- Echtzeit-Monitoring,
- Benachrichtigungssysteme,
- Anwendungen mit zahlreichen Background-Prozessen.
Ein weiterer Vorteil kann die einfachere Skalierung einzelner Komponenten sein. Wenn beispielsweise der Payment Service deutlich mehr Anfragen verarbeitet als andere Teile des Systems, kann genau dieser Service unabhängig skaliert werden.
Für eine kleine und einfache Anwendung kann eine eventbasierte Architektur dagegen unnötige Komplexität schaffen. Sie führt zusätzliche Komponenten ein, die überwacht, gewartet und verwaltet werden müssen.
Fazit
Event-Driven Architecture ermöglicht es Anwendungen, auf Ereignisse zu reagieren, ohne dass die einzelnen Komponenten eng miteinander verbunden sein müssen. Dadurch können Systeme flexibler, skalierbarer und robuster werden.
Allerdings benötigt nicht jede Anwendung Kafka, RabbitMQ oder eine komplexe eventbasierte Architektur. Der wichtigste Schritt besteht darin, zunächst zu verstehen, welches Problem gelöst werden soll, und erst danach die Architektur und Technologien auszuwählen, die am besten zu den Anforderungen passen.