Event-Driven Architecture
Event-Driven Architecture (EDA) ist ein Architekturstil, bei dem Systeme über Ereignisse kommunizieren: Sobald etwas Relevantes passiert – etwa eine neue Bestellung –, erzeugt ein System ein Ereignis, das andere Systeme entkoppelt und in Echtzeit auslesen und darauf reagieren. Statt sich direkt aufzurufen, tauschen die Bausteine Nachrichten über einen Vermittler aus.
Event-Driven Architecture (EDA), auf Deutsch ereignisgesteuerte Architektur, ist ein Muster für den Aufbau verteilter Software: Die beteiligten Systeme oder Dienste kommunizieren nicht, indem sie sich direkt aufrufen, sondern indem sie „Ereignisse“ (Events) austauschen. Ein Ereignis ist die Feststellung, dass etwas Bedeutsames geschehen ist – eine Bestellung wurde aufgegeben, eine Zahlung ging ein, ein Bestand hat sich geändert. Das System, in dem das passiert, veröffentlicht diese Tatsache als Nachricht; andere Systeme, die daran interessiert sind, empfangen sie und reagieren eigenständig. Sender und Empfänger kennen sich dabei nicht direkt – sie sind über einen Vermittler entkoppelt.
Der Kern von EDA ist diese Entkopplung in Raum und Zeit: Der Erzeuger eines Ereignisses muss nicht wissen, wer es verarbeitet, ob es überhaupt jemand verarbeitet oder wann das geschieht. Dadurch lassen sich Systeme unabhängig voneinander weiterentwickeln, skalieren und ausfallsicher betreiben. Im ERP- und E-Commerce-Umfeld ist EDA die Grundlage dafür, dass Shop, Marktplatz, Warenwirtschaft, Buchhaltung und Versand nahezu in Echtzeit zusammenspielen, ohne zu einem starren Block verschmolzen zu sein.
Auf einen Blick
- EDA = Architekturstil, bei dem Systeme über Ereignisse (Events) statt über direkte Aufrufe kommunizieren
- Zentrale Rollen: Producer (erzeugt Events), Broker/Event-Bus (vermittelt), Consumer (reagiert)
- Starke Entkopplung: Sender kennt Empfänger nicht – Systeme skalieren und entwickeln sich unabhängig
- Ermöglicht Echtzeit-Reaktionen und hohe Ausfallsicherheit, erhöht aber die Komplexität im Betrieb
- Im ERP-Umfeld die Basis für reaktionsschnelle Integration von Shop, Payment, Lager und Buchhaltung
Wie Event-Driven Architecture funktioniert
Eine Event-Driven Architecture kennt drei Grundrollen. Der Producer (Erzeuger) stellt fest, dass ein Ereignis eingetreten ist, und veröffentlicht es. Der Consumer (Verbraucher) hat Interesse an bestimmten Ereignissen, empfängt sie und löst eine Reaktion aus. Dazwischen steht ein Vermittler – je nach Umsetzung ein Event-Broker, eine Message Queue oder ein Event-Bus –, der die Ereignisse entgegennimmt, zwischenspeichert und an alle interessierten Empfänger verteilt. Der Producer schickt sein Ereignis also nicht an einen konkreten Adressaten, sondern „in den Raum“; wer es abholt, entscheidet der Broker anhand von Abonnements.
Ein Ereignis selbst ist ein kompakter, unveränderlicher Datensatz – meist im Format JSON –, der beschreibt, was passiert ist: ein Ereignistyp (z. B. „BestellungAufgegeben“), ein Zeitstempel und die relevanten Nutzdaten wie Bestellnummer und Positionen. Wichtig ist der Unterschied zwischen einem Event und einem Befehl: Ein Event meldet neutral eine bereits eingetretene Tatsache in der Vergangenheit, ohne vorzuschreiben, was zu tun ist. Ein Befehl (Command) fordert dagegen eine bestimmte Aktion an. Diese Umkehrung – „etwas ist geschehen“ statt „tu dies“ – erlaubt es, jederzeit neue Empfänger hinzuzufügen, ohne den Producer zu ändern.
Publish-Subscribe und Event-Streaming
Zwei Spielarten dominieren die Praxis. Beim Publish-Subscribe-Muster (Pub/Sub) veröffentlicht ein Producer Ereignisse in einem „Topic“ (Themenkanal); alle Consumer, die dieses Topic abonniert haben, erhalten eine Kopie. So kann ein einziges Bestellereignis parallel die Buchhaltung, das Lager und ein Analyse-Dashboard erreichen. Beim Event-Streaming – etwa mit Plattformen wie Apache Kafka – werden Ereignisse zusätzlich als dauerhafter, geordneter Verlauf („Log“) gespeichert. Consumer können den Strom von einem beliebigen Punkt aus lesen, verpasste Ereignisse nachholen und den Verlauf erneut abspielen. Das ist die Grundlage für Konzepte wie Event Sourcing, bei dem der aktuelle Zustand eines Systems aus der lückenlosen Historie aller Ereignisse rekonstruiert wird.
Warum Event-Driven Architecture wichtig ist
Der wichtigste Nutzen von EDA ist die lose Kopplung. Weil ein Producer nicht weiß und nicht wissen muss, wer seine Ereignisse verarbeitet, lassen sich einzelne Dienste austauschen, aktualisieren oder ergänzen, ohne die übrigen anzufassen. Kommt ein neuer Verkaufskanal hinzu, abonniert er einfach die vorhandenen Bestellereignisse – am erzeugenden System ändert sich nichts. Diese Unabhängigkeit senkt das Risiko, dass eine Änderung an einer Stelle unbeabsichtigt an anderer Stelle etwas zerstört.
Zweitens ermöglicht EDA Echtzeit-Reaktionen: Statt in festen Abständen nachzufragen, ob sich etwas geändert hat, reagieren Systeme in dem Moment, in dem das Ereignis eintritt. Drittens verbessert die Entkopplung über einen Broker die Ausfallsicherheit und Lastverteilung – fällt ein Consumer kurz aus, bleiben seine Ereignisse in der Queue liegen und werden nachgeholt, statt verloren zu gehen. Und viertens skaliert das Modell gut: Bei Lastspitzen lassen sich mehrere Consumer parallel auf denselben Ereignisstrom setzen. Diese Eigenschaften machen EDA zum bevorzugten Kommunikationsmuster für Microservices und composable, aus Bausteinen zusammengesetzte Systemlandschaften.
Event-Driven Architecture im ERP-System
Ein ERP ist der zentrale Datendrehpunkt eines Unternehmens – und genau deshalb ist EDA hier so wertvoll. In einer ereignisgesteuerten Landschaft meldet der Onlineshop das Ereignis „Bestellung eingegangen“, worauf das ERP den Auftrag anlegt, den Bestand reserviert und selbst ein Folgeereignis „Auftrag angelegt“ veröffentlicht. Der Zahlungsdienstleister meldet „Zahlung bestätigt“, das Lager reagiert mit der Kommissionierung, der Versanddienst quittiert „Paket versendet“, und die Buchhaltung verbucht parallel den Vorgang. Jeder Schritt ist ein Ereignis, auf das mehrere Systeme unabhängig reagieren – eine Kette, die ohne zentrale Steuerung abläuft.
In der Praxis werden einzelne Ereignisse häufig über Webhooks ausgeliefert, während Middleware- oder iPaaS-Plattformen als Event-Broker und Übersetzer dienen. Sie nehmen Ereignisse an, transformieren sie in das jeweils passende Datenformat und verteilen sie an die Zielsysteme. So entsteht ein reaktionsschneller Datenfluss, der die Bestandssynchronisation über alle Kanäle hinweg aktuell hält und Überverkäufe vermeidet. EDA ist damit ein zentraler Baustein moderner Integration – besonders in composable- und Best-of-Breed-Ansätzen, bei denen viele spezialisierte Systeme zusammenarbeiten müssen.
Herausforderung Idempotenz und Reihenfolge
Ereignisgesteuerte Systeme bringen typische Fallstricke mit. Ein Broker garantiert oft nur, dass ein Ereignis „mindestens einmal“ zugestellt wird – es kann also doppelt ankommen. Consumer müssen deshalb idempotent arbeiten, damit ein zweimal empfangenes „Zahlung bestätigt“ nicht zu einer Doppelbuchung führt. Ebenso ist die Reihenfolge nicht immer garantiert: Trifft „Auftrag storniert“ vor „Auftrag angelegt“ ein, muss der Empfänger dies anhand von Zeitstempeln oder Statusfeldern sauber auflösen. Diese Anforderungen sind beherrschbar, gehören aber von Anfang an in jedes Integrationsprojekt.
Abgrenzung: EDA vs. Request-Response und ESB
Der Gegenpol zu EDA ist die klassische Request-Response-Kommunikation, bei der ein System ein anderes direkt über eine API aufruft und synchron auf die Antwort wartet. Dieses Muster ist einfach und gut nachvollziehbar, koppelt die Systeme aber eng: Der Aufrufer muss den Aufgerufenen kennen und darauf warten, dass dieser erreichbar ist und antwortet. EDA arbeitet dagegen asynchron und entkoppelt – niemand wartet, und der Producer läuft weiter, auch wenn ein Consumer gerade nicht verfügbar ist. In realen Landschaften ergänzen sich beide Muster: Request-Response für sofortige Abfragen, EDA für die Verteilung von Ereignissen.
Vom Enterprise Service Bus (ESB) unterscheidet sich EDA vor allem in der Ausrichtung. Ein ESB, ein Konzept der klassischen SOA, stellt eine zentrale, oft intelligente Integrationsschicht bereit, die Routing, Transformation und Orchestrierung übernimmt. EDA verlagert die Logik dagegen an die Ränder: Der Broker vermittelt möglichst „dumm“ nur Ereignisse, die Consumer entscheiden selbst, wie sie reagieren. Das macht das Gesamtsystem flexibler und leichter erweiterbar, verteilt die Komplexität aber auf viele Dienste – was Beobachtbarkeit, Monitoring und ein durchdachtes Fehlerhandling umso wichtiger macht.
Praxisbeispiel
Beispiel: Ein Bestellereignis löst eine ganze Kette aus
Ein mittelständischer Händler für Haushaltswaren verkauft über einen eigenen Shop und zwei Marktplätze. Als ein Kunde eine Küchenmaschine bestellt, veröffentlicht der Shop das Ereignis „BestellungAufgegeben“ mit Bestellnummer, Artikel und Menge an den Event-Broker der angebundenen Integrationsplattform. Der Broker verteilt es an alle interessierten Systeme.
Das ERP empfängt das Ereignis, legt den Auftrag an, reserviert den Bestand und veröffentlicht seinerseits „BestandGeändert“ – woraufhin die beiden Marktplätze ihre Verfügbarkeit anpassen und ein Überverkauf ausgeschlossen ist. Parallel wartet der Versanddienst auf das Ereignis „ZahlungBestätigt“ des Zahlungsdienstleisters, um die Kommissionierung anzustoßen, und ein Analyse-Dashboard zählt die Bestellung in Echtzeit mit. Keines dieser Systeme kennt die anderen direkt; jedes reagiert nur auf die Ereignisse, die es abonniert hat. Fällt das Dashboard kurz aus, holt es die verpassten Ereignisse später aus dem Stream nach – die Auftragsabwicklung läuft davon unberührt weiter.
Häufige Fragen
Passende ERP-Systeme
Passende Leistungen
Fragen zu Event-Driven Architecture in deinem ERP-Projekt?
Wir beraten herstellerunabhängig – und setzen es auf Wunsch selbst um.