Event-getriebene Architektur: Wie Sie Echtzeit-Datenströme nutzen, statt Systeme im Takt abzufragen

Eine Event-getriebene Architektur lässt Systeme auf Ereignisse reagieren, sobald sie eintreten, statt in festen Abständen nachzufragen, ob sich etwas geändert hat. Für IT-Leitungen mit gewachsenen Landschaften ist sie der Weg, Insellösungen zu entkoppeln, ohne jede Verbindung einzeln zu programmieren.

Was eine Event-getriebene Architektur ist

In einer Event-getriebenen Architektur sind Komponenten lose gekoppelt und kommunizieren über Ereignisse (Events). Ein Erzeuger meldet „Bestellung eingegangen“ an einen Event-Bus; Lagerverwaltung, Rechnungsstellung und Versand reagieren darauf, jeder für sich und ohne dass der Erzeuger sie kennen muss. Der Unterschied zum synchronen Aufruf über eine REST-Schnittstelle: Der Erzeuger wartet nicht auf Antwort. Fällt der Versanddienst aus, bleibt die Bestellung im Bus liegen und wird verarbeitet, sobald er zurück ist. Genau diese Entkopplung macht das Muster für gewachsene Landschaften interessant, in denen jedes System bisher jedes andere direkt aufruft.

Insellösungen zusammenführen: Plattform oder Event-Bus?

Wenn mehrere Systeme dieselben Daten brauchen, gibt es zwei Wege. Eine zentrale Plattform, in die alle Daten fließen und aus der alle lesen, oder ein Event-Bus, über den jedes System die Ereignisse abonniert, die es betreffen. Die Plattform ist der richtige Weg, wenn Sie eine gemeinsame Sicht auf Stammdaten brauchen. Der Event-Bus ist der richtige Weg, wenn Systeme in Echtzeit auf Änderungen reagieren sollen, ohne sich gegenseitig zu blockieren. In den meisten Landschaften braucht es beides, und der Fehler ist, die Entscheidung gar nicht bewusst zu treffen, sondern die nächste Punkt-zu-Punkt-Schnittstelle zu bauen. Ein Logistiker, der Sendungsereignisse über einen Bus an Kunden und interne Systeme verteilt, spart sich die Abfragen, die bisher alle paar Minuten gegen das Transportsystem liefen. Wie Schnittstellen dafür sauber entworfen werden, beschreibt der Beitrag API-First-Design für vernetzte Systeme.

Die Bausteine

Erzeuger und Verbraucher

Erzeuger senden Ereignisse wie „Sensorwert überschritten“, Verbraucher verarbeiten sie, etwa als Alarm oder Protokolleintrag. Beide skalieren unabhängig. In einer Fertigung senden Maschinen Messwerte als Ereignisse; ein Verbraucher prüft auf Abweichungen, ein anderer schreibt für die Qualitätssicherung mit.

Event-Bus und Nachrichtenbroker

Der Bus, etwa Apache Kafka oder RabbitMQ, speichert Ereignisse dauerhaft und verteilt sie. Er sorgt dafür, dass nichts verloren geht und dass sich Ereignisse erneut abspielen lassen, etwa für eine Prüfung oder wenn ein Verbraucher neu aufgesetzt wird. Ein Finanzinstitut hält Transaktionsereignisse im Bus vor und rekonstruiert daraus im Nachhinein jeden Zustand.

Verarbeitung im Strom oder im Stapel

Stromverarbeitung wertet Ereignisse sofort aus, Stapelverarbeitung in Intervallen. Für Betrugserkennung oder Alarme ist nur die Stromverarbeitung brauchbar: Eine Bank erkennt ein ungewöhnliches Transaktionsmuster, während es passiert, nicht in der Nachtverarbeitung.

Einführung in vier Schritten

Geschäftsereignisse benennen

Suchen Sie in Ihren Abläufen die wiederkehrenden Ereignisse: Auftrag eingegangen, Zahlung bestätigt, Lagerbestand niedrig, Maschine gestört. Legen Sie für jedes ein Schema fest, in dem steht, welche Felder es trägt. Ohne Schema wird der Bus zur Müllhalde.

Technik wählen

Apache Kafka für hohen Durchsatz und dauerhafte Speicherung, RabbitMQ für einfachere Abläufe. Cloud-Dienste der großen Anbieter sind bequem, binden aber. Für Daten, die in Deutschland bleiben müssen, betreiben wir den Bus selbst auf souveräner Infrastruktur, mit offenen Standards.

Klein anfangen

Starten Sie mit einem unkritischen Ablauf wie Benachrichtigungen. Bauen Sie Verbraucher idempotent, damit ein doppelt zugestelltes Ereignis keinen doppelten Effekt hat. Nutzen Sie Event Sourcing, wenn Sie Zustände aus der Ereignisfolge rekonstruieren wollen. Ein Händler beginnt mit „Bestellung versandt“ und ergänzt Ereignis für Ereignis.

Betrieb absichern

Überwachen Sie Latenz, Durchsatz und Fehlerrate je Verbraucher. Fehlgeschlagene Ereignisse landen in einer Warteschlange für Nacharbeit, nicht im Nichts. Ein Logistiker stellt so sicher, dass eine verpasste Zollfreigabe automatisch nachgeholt wird.

Die Fallstricke

Verzögerte Konsistenz

Weil Ereignisse asynchron verarbeitet werden, sind Daten für kurze Zeit nicht überall gleich. Für viele Abläufe ist das unproblematisch, für Buchungen nicht. Das Saga-Muster koordiniert verteilte Vorgänge und löst bei Fehlern ausgleichende Ereignisse aus. Eine Buchungsplattform hält Hotel- und Flugbuchung so konsistent, auch wenn ein Schritt scheitert.

Fehlersuche über Systemgrenzen

Die lose Kopplung macht es schwerer, einen Vorgang zu verfolgen. Verteiltes Tracing mit OpenTelemetry und eine Korrelations-ID, die jedes Ereignis mitträgt, machen den Weg durch alle Dienste sichtbar.

Personendaten im Bus

Ereignisse enthalten oft personenbezogene Daten. Sie werden auf dem Weg und im Speicher verschlüsselt, der Zugriff auf den Bus ist beschränkt, und für Löschfristen nach der Datenschutz-Grundverordnung braucht es ein Konzept, weil ein dauerhafter Ereignisspeicher nicht einfach vergisst. Ein Gesundheitsunternehmen pseudonymisiert Patientendaten, bevor sie den Bus erreichen.

Häufige Fragen

Was ist der Unterschied zwischen Event-getriebener Architektur und Microservices?

Microservices beschreiben den Zuschnitt in kleine, unabhängige Dienste. Die Event-getriebene Architektur beschreibt, wie Systeme asynchron über Ereignisse kommunizieren. Das Muster funktioniert auch innerhalb eines Monolithen.

Ist das Muster für kleinere Unternehmen geeignet?

Ja, wenn es einen echten Anwendungsfall gibt: ein Ereignis, auf das mehrere Systeme reagieren müssen. Der Einstieg mit einem einfachen Broker und einem Fall ist überschaubar. Ohne Anwendungsfall ist der Bus nur Infrastruktur, die gepflegt werden will.

Was ist bei der Sicherheit zu beachten?

Verschlüsselung auf dem Transportweg, Authentifizierung und Berechtigungen für Erzeuger und Verbraucher, Schutz vor erneut eingespielten Ereignissen und ein Löschkonzept für personenbezogene Daten.

Nehmen Sie den einen Vorgang, bei dem heute drei oder mehr Systeme voneinander erfahren müssen, und zeichnen Sie auf, wer wen wie oft abfragt. Mit dieser Skizze zeigen wir Ihnen im Potenzial-Check, eine halbe Stunde, kostenlos, ob ein Event-Bus die Abfragen ersetzt oder ob eine Plattform der bessere Weg ist. Potenzial-Check buchen