Event-driven Architecture (EDA) ist eine Art, Software so zu bauen, dass die Teile eines Systems miteinander kommunizieren, indem sie bekannt geben, dass etwas passiert ist, statt sich direkt gegenseitig aufzurufen. Eine Komponente veröffentlicht ein Event, etwa „Rechnung bezahlt“ oder „Vertrag unterzeichnet“. Jede andere Komponente, die sich dafür interessiert, reagiert darauf. Keine Seite muss von der anderen wissen.

Für ein SaaS-Unternehmen ist das weit über die Technik hinaus relevant. Derselbe Gedanke steckt hinter sauberen Übergaben vom CRM an die Finanzabteilung, zuverlässiger Automatisierung und KI-Agenten, die auf aktuellen Daten arbeiten. Dieser Leitfaden erklärt, wie EDA funktioniert, worin sich ein Event Bus von einer Queue unterscheidet, wie Sie typische Fehler vermeiden und wo EDA hingehört und wo nicht.

Kurz gefasst

Inhaltsverzeichnis

Was Event-driven Architecture ist

Die Architekturempfehlungen von Microsoft beschreiben den Stil als Event-Producer, die einen Strom von Events erzeugen, Event-Consumer, die darauf warten, und Event-Kanäle, die Events vom einen zum anderen transportieren. Dieses dreiteilige Modell ist der gesamte Grundgedanke. Alles andere sind Details dazu, wie zuverlässig und wie schnell der Kanal arbeitet.

Der Gegensatz ist Request/Response. Bei einem Request/Response-Design ruft Ihr Billing-Service Ihr CRM auf und wartet auf eine Antwort. Ist das CRM langsam oder nicht erreichbar, steckt das Billing fest. Bei einem ereignisgesteuerten Design veröffentlicht das Billing „Zahlung eingegangen“ und macht weiter. Das CRM, der Umsatzbericht und das Customer-Success-Dashboard greifen das Event jeweils auf, wenn sie bereit sind.

Daraus ergeben sich zwei Eigenschaften:

Was als Event gilt

Ein Event ist eine Tatsachenfeststellung in der Vergangenheitsform. Red Hat beschreibt es als einen unveränderlichen Datensatz darüber, dass etwas passiert ist, oft mit einem Zeitstempel, der die Reihenfolge relativ zu dem System erhält, das es erzeugt hat. Ein Event wird nachträglich nicht bearbeitet. Ändert sich etwas, hält ein neues Event die Änderung fest.

AWS weist darauf hin, dass Events eine Zustandsänderung oder eine Aktualisierung sein können und entweder den Zustand mitführen oder Kennungen sein können. Zwei Beispiele:

Stil Beispiel Was der Consumer erhält
Event mit Zustand Abonnement hochgestuft, mit Tarif, Preis, Gültigkeitsdatum, Konto-ID Alles, was nötig ist, um ohne zweite Abfrage zu handeln
Event als Kennung Bestellung versandt, nur mit der Bestell-ID Ein Signal. Der Consumer holt die Details aus dem Quellsystem

Die erste Variante ist bequem, koppelt die Consumer aber an die Form des Events. Die zweite hält Events klein, schickt die Consumer jedoch zurück zum Quellsystem, was die Frage aufwirft, welches System maßgeblich ist. Darauf kommen wir weiter unten zurück, denn genau hier haben die meisten SaaS-Betriebs-Stacks Schwierigkeiten.

Ein Command ist kein Event. „Rechnung senden“ ist eine Anweisung an einen bestimmten Empfänger. „Rechnung gesendet“ ist eine Tatsache, auf die jeder reagieren kann. Beides zu vermischen ist ein häufiger Entwurfsfehler und baut unbemerkt die enge Kopplung wieder auf, die Sie beseitigen wollten.

Wie ein ereignisgesteuertes System funktioniert, Schritt für Schritt

Die Dokumentation von Google Cloud beschreibt den Ablauf: Produzenten erzeugen Ereignisse, ein Router oder Broker nimmt sie entgegen und filtert sie und verteilt sie dann auf Basis von Abonnements oder Triggern an die Konsumenten. In der Praxis:

  1. Etwas passiert. Ein Deal wird im CRM auf „Closed Won“ gesetzt.
  2. Der Produzent veröffentlicht ein Ereignis. Es nennt den Sachverhalt und den betroffenen Datensatz.
  3. Der Broker leitet es weiter. Er filtert das Ereignis und stellt es jedem Abonnenten zu.
  4. Die Konsumenten reagieren unabhängig voneinander. Die Finanzabteilung erstellt einen Rechnungsentwurf. Customer Success legt einen Onboarding-Plan an. Ein Provisioning-Prozess bereitet Zugänge vor.
  5. Jeder Konsument bestätigt den Empfang. Der Broker weiß, dass das Ereignis verarbeitet wurde, und kann es erneut zustellen, falls nicht.

IBM beschreibt dasselbe Muster als Veröffentlichung, Erfassung, Verarbeitung und Speicherung von Ereignissen und weist darauf hin, dass sich der Wert eines Ereignisses im Lauf der Zeit ändern kann. Auf ein Ereignis „neuer Lead“ lohnt es sich, innerhalb von Minuten zu reagieren. Ein Jahr später ist es vor allem für Analysen nützlich.

Event-driven Architecture und Microservices

Oft werden diese Begriffe gleichgesetzt. Das sind sie nicht. Microservices beschreiben, wie Sie eine Anwendung in kleine, unabhängig bereitgestellte Dienste aufteilen. EDA beschreibt, wie diese Dienste kommunizieren. Es gibt Microservices, die sich gegenseitig synchron aufrufen, und es gibt Monolithen, die intern Ereignisse veröffentlichen.

Beides ergänzt sich gut. Googles Leitfaden hält fest, dass Microservices asynchron auf Ereignisse reagieren können und nur das Ereignisformat kennen müssen, nicht die Geschäftslogik der anderen. Dieses gemeinsame Format ist der Vertrag. Alles dahinter kann sich ändern.

Die Dokumentation von Microsoft beschreibt das typische Muster als Microservices, die ein Ereignis veröffentlichen, wenn etwas Bemerkenswertes geschieht, während andere Microservices es abonnieren.

Event Bus vs. Queue vs. Stream

Diese drei Begriffe sorgen für die meiste Verwirrung, und die Wahl verändert das Verhalten Ihres Systems.

Event Bus (Publish/Subscribe). Ein Event Bus ist ein Mechanismus, bei dem Publisher Ereignisse bekannt geben und Subscriber sie empfangen. Microsoft erläutert, dass er auf einer Messaging-Infrastruktur wie einer Queue oder einem Service Bus umgesetzt werden kann, die asynchrones Publish/Subscribe unterstützt. Eine Queue kann also ein Baustein eines Bus sein. Der Bus ist die Absicht. Die Queue ist eine Möglichkeit, sie umzusetzen.

Queue. Eine Queue hält Nachrichten vor, bis ein Worker sie abholt. Jede Nachricht wird normalerweise von genau einem Konsumenten verarbeitet. Queues sind das richtige Werkzeug, um Arbeit auf mehrere Worker zu verteilen und Lastspitzen abzufangen. Die Integrationsempfehlungen von Azure nennen das Einreihen von Nachrichten, wenn ein Back-End nicht verfügbar ist, als einen Grund für den Einsatz eines Brokers.

Event Stream. Azure unterscheidet Publish/Subscribe von Streaming. Bei Publish/Subscribe wird ein Ereignis nach dem Empfang nicht in einem dauerhaften Log gespeichert, sodass neue Subscriber vergangene Ereignisse nicht sehen. Beim Streaming werden Ereignisse in ein Log geschrieben, das dauerhaft und innerhalb einer Partition streng geordnet ist, und Clients lesen aus dem Log, können jederzeit einsteigen und Ereignisse erneut abspielen.

Queue Publish/Subscribe-Bus Event Stream
Zustellung Ein Konsument pro Nachricht Jeder Subscriber Jeder Leser, ab jedem beliebigen Punkt
Vergangene Ereignisse Nach der Verarbeitung entfernt Für neue Subscriber nicht verfügbar Gespeichert und erneut abspielbar
Typischer Einsatz Arbeitsverteilung, Pufferung Mehrere Systeme benachrichtigen Historie, Analysen, Zustand wiederherstellen

Eine praktische Faustregel: Wenn mehrere Systeme auf denselben Sachverhalt reagieren sollen, verwenden Sie Publish/Subscribe. Wenn ein Worker eine Aufgabe erledigen soll, verwenden Sie eine Queue. Wenn Sie eine Historie benötigen oder ein nachgelagertes System neu aufbauen können müssen, verwenden Sie einen Stream. Red Hat ergänzt, dass es keine Universallösung gibt, wählen Sie die Technologie also nach Ereignistyp.

Ist Kafka eine Event-driven Architecture?

Nein. Kafka ist eine Technologie, mit der Sie eine solche Architektur aufbauen können. Die Apache-Kafka-Dokumentation beschreibt sie als Plattform für Event Streaming: Ereignisse in Echtzeit erfassen, dauerhaft speichern, verarbeiten und an andere Systeme weiterleiten. Damit ist sie ein Event Stream im Sinne der obigen Tabelle.

Eine Architektur ist eine Reihe von Designentscheidungen: Was die Ereignisse sind, wem sie gehören, wie Konsumenten voneinander isoliert werden und was im Fehlerfall passiert. Diese Entscheidungen können Sie treffen und auf einem verwalteten Cloud-Bus, einem Queue-Dienst oder Kafka betreiben. Sie können auch Kafka betreiben und trotzdem ein eng gekoppeltes System haben, wenn jeder Dienst von den internen Ereignissen eines anderen Dienstes abhängt. Wählen Sie das Werkzeug erst, nachdem Sie die Ereignisse und das tatsächlich erwartete Volumen festgelegt haben.

Ereignisgesteuerte Integration und Automatisierung

Hier wird EDA für Verantwortliche im operativen Geschäft relevant und nicht nur für Entwickler.

Integration

Die meisten SaaS-Unternehmen verbinden ihre CRM-, Abrechnungs-, Support- und Produktdaten über Punkt-zu-Punkt-Synchronisierungen. Jedes neue Tool fügt eine weitere Verbindung hinzu, die gepflegt werden muss. Azure empfiehlt asynchrone Kommunikation über einen Message Broker statt direkter synchroner Aufrufe, und zwar aus vier genannten Gründen: Anwendungen entkoppeln, an mehrere Konsumenten senden, lang laufende Workflows zuverlässig nachverfolgen und Nachrichten einreihen, wenn ein Back-End nicht verfügbar ist.

Der Vorteil zeigt sich, wenn Sie ein System hinzufügen. Bei einem Publish/Subscribe-Dienst können neue Subscriber hinzugefügt werden, ohne den Sender zu aktualisieren. Ein neues Analyse-Tool erfordert keine Änderung an Ihrem CRM.

Automatisierung

Ereignisgesteuerte Automatisierung bedeutet, dass ein Geschäftsprozess startet, weil etwas passiert ist, und nicht, weil jemand auf eine Schaltfläche geklickt hat oder ein nächtlicher Job lief. Der Flow-Leitfaden von ServiceNow nennt eine praktische Methode: den Trigger bestimmen, die Logik planen, die Aktionen auswählen und wiederverwendbare Logik identifizieren. Außerdem wird empfohlen, Flows fokussiert zu halten und pro Aktion ein Verb zu verwenden.

Wenn ein Prozess mehrere Dienste umfasst, verweist Microsoft darauf, dass ereignisgesteuerte Systeme zur Koordination des Ablaufs häufig Choreographie- und Saga-Orchestrierungsmuster einsetzen. Bei der Choreographie reagiert jeder Dienst auf Ereignisse und sendet eigene. Bei der Orchestrierung sagt ein Koordinator jedem Schritt, was zu tun ist, und verfolgt den gesamten Prozess. Für ein erstes Projekt ist ein orchestrierter Ablauf meist leichter zu lesen und zu prüfen.

Ein einfaches SaaS-Beispiel:

Best Practices und typische Herausforderungen

Azure nennt die wichtigsten Herausforderungen: eventuelle Konsistenz, asynchrone Fehlerbehandlung, Datenverlust, Observability und Tests, zu viele oder zu stark zusammengefasste Events sowie Schema-Evolution. Für jede gibt es eine passende Praxis.

  1. Planen Sie mit eventueller Konsistenz. Systeme werden kurzzeitig voneinander abweichen. Legen Sie fest, welches System für welchen Fakt maßgeblich ist, und lassen Sie die anderen diesem folgen.
  2. Richten Sie eine eigene Fehlerbehandlung ein. Fehlgeschlagene Events brauchen einen Ort, an den sie gelangen, und jemanden, der sie prüft.
  3. Bewahren Sie Events auf, bis der Empfang bestätigt ist. Das schützt vor Datenverlust, wenn ein Empfänger ausfällt.
  4. Nutzen Sie Korrelations-IDs. Eine ID, die durch jeden Schritt mitgeführt wird, lässt Sie eine einzelne Kundenaktion systemübergreifend nachverfolgen.
  5. Finden Sie die richtige Granularität der Events. Ein Event pro Feldänderung erzeugt Rauschen. Ein riesiges Event für alles schafft die enge Kopplung wieder.
  6. Versionieren Sie Schemas frühzeitig. Eventformate werden sich ändern. Entscheiden Sie, wie, bevor Sie zwanzig Empfänger haben.

Dem würden wir drei operative Gewohnheiten hinzufügen: Ereignisse in der Vergangenheitsform benennen, jedem Ereignistyp genau einen Verantwortlichen zuweisen und schriftlich festhalten, welche Konsumenten davon abhängen.

Wo ereignisgesteuertes Design nicht hingehört

EDA ist nicht die Antwort auf jedes Problem. Machen Sie sich die Grenzen klar, bevor Sie sich festlegen:

Dieselbe Logik gilt für KI. Ein KI-Assistent, der Ihre Systeme liest und darin handelt, ist Empfänger und Erzeuger von Events. Liest er inkonsistente Daten oder handelt er ohne Berechtigungsgrenze, machen Sie Fehler nur schneller.

Wo das auf KI-Agenten und Compliance trifft

KI-Agenten, die Daten abrufen (fragen, berichten, nachschlagen) und Daten schreiben (einen Datensatz aktualisieren, einen Prozess auslösen, Zugriff bereitstellen), verhalten sich wie Teilnehmer eines ereignisgesteuerten Systems. Sie brauchen eine vertrauenswürdige Quelle zum Lesen, einen klaren Satz erlaubter Aktionen, eine Freigabe für sensible Schritte und ein Protokoll ihrer Handlungen. Ein Event-Log ist dafür ein naheliegender Ort.

Bearbeiter prüft das Event-Log eines KI-Agenten

Für europäische Unternehmen wirken sich DSGVO, NIS2 und der EU AI Act darauf aus, wie solche Systeme gestaltet werden. Allgemein betreffen sie, welche personenbezogenen Daten durch Events fließen, wie Sicherheit und Vorfallsbehandlung organisiert sind und wie KI-Systeme gesteuert und dokumentiert werden. Betrachten Sie sie von Anfang an als Designvorgaben und lassen Sie sich von Rechtsberatern dazu beraten, wie sie in Ihrem konkreten Fall gelten. Keine Architekturentscheidung allein macht ein System konform.

Unsere Sichtweise

Die meisten SaaS-Unternehmen, mit denen wir sprechen, haben kein Event-Problem. Sie haben ein Verantwortungsproblem. Mehrere Teams nutzen KI, mehrere Tools halten eine Version des Kunden vor, und niemand ist dafür verantwortlich, welche Version stimmt.

Deshalb arbeiten wir in einer festen Reihenfolge. Zuerst die Datenbasis: die CRM- und Finanzdaten als vereinbarte maßgebliche Quelle. Dann die KI-Schicht, die diese Daten mit dem Assistenten verbindet, den Ihr Team bereits nutzt. Danach Abteilungsagenten für Finance, Sales und Customer Success. Events sind auf allen drei Ebenen nützlich, helfen aber erst, wenn die Fakten, die sie transportieren, geklärt sind.

Außerdem führen wir immer nur einen Prozess nach dem anderen ein, beginnend mit dem teuersten. Ein Verlängerungsprozess oder die Übergabe von Rechnung bis Zahlungseingang ist ein besseres erstes ereignisgesteuertes Projekt als ein unternehmensweiter Umbau. Sie sehen das Ergebnis, Ihre Leute lernen das Muster, und der nächste Prozess wird günstiger.

Da wir den Betrieb übernehmen und nicht nur Systeme entwerfen, kümmern wir uns um die unspektakulären Teile: Berechtigungen, Freigaben, Audit-Trails und eine Übergabe, bei der Code, Dokumentation und Infrastruktur Ihnen gehören.

Claus Nielsen

Der Einstieg in Ihrem eigenen Unternehmen

Sie müssen nicht zuerst einen Broker auswählen. Beginnen Sie mit diesen Fragen:

  1. Welcher Prozess kostet Sie am meisten durch manuelle Arbeit, Verzögerungen oder Fehler?
  2. Welche zwei oder drei Events lösen ihn aus (zum Beispiel Deal abgeschlossen, Rechnung überfällig, Verlängerung steht an)?
  3. Welches System ist die maßgebliche Quelle für die Daten in diesen Events?
  4. Wer ist für jede Event-Definition verantwortlich?
  5. Welche Schritte brauchen eine menschliche Freigabe?

Wenn Sie die dritte Frage nicht beantworten können, kommt zuerst die Datenbasis. Wenn Sie es können, zeigt Ihnen ein kleiner Pilot an einem Prozess, ob sich ein ereignisgesteuerter Ansatz lohnt.

Wie wir helfen können

Wenn Ihr Team KI nutzt, aber niemand dafür verantwortlich ist, helfen wir Ihnen zu entscheiden, wo sie sich lohnt, und sie in der richtigen Reihenfolge aufzubauen. Unser AI Readiness Assessment ist ab €4,500 erhältlich und untersucht Ihre Daten, Systeme und Prozesse, bevor etwas gebaut wird. Wenn Sie laufende Führung wünschen, beginnt das Fractional Chief AI Officer Retainer bei €1,500 pro Monat.

Umsetzungen werden mit 30% der gemessenen und nachgewiesenen Einsparung im ersten Jahr berechnet oder zu einem vor Arbeitsbeginn vereinbarten Festpreis. Über unsere Website können Sie außerdem ein kostenloses 30-minütiges Kennenlerngespräch buchen. Unsere KI-Agenten für Finance, Sales und Customer Success zeigen, wie die Abteilungsebene aussieht, sobald das Fundament steht.

FAQ

Was ist ereignisgesteuerte Architektur in einfachen Worten?

Es ist ein Design, bei dem Softwarekomponenten bekannt geben, dass etwas passiert ist, und andere Komponenten darauf reagieren. Der Sender weiß nicht, wer zuhört. So können Sie Systeme hinzufügen oder ändern, ohne diejenigen umzuschreiben, die die Events erzeugen.

Was ist der Unterschied zwischen einem Event-Bus und einer Message Queue?

Eine Queue liefert jede Nachricht in der Regel an einen Worker. Ein Event-Bus liefert jedes Event an alle Abonnenten. Ein Bus kann auf einer Queue-Infrastruktur aufgebaut sein, der Unterschied liegt also in der Absicht und im Zustellmuster, nicht immer im Produkt.

Ist ereignisgesteuerte Architektur dasselbe wie Microservices?

Nein. Bei Microservices geht es darum, wie eine Anwendung in Services aufgeteilt wird. Bei ereignisgesteuerter Architektur geht es darum, wie Teile kommunizieren. Beides wird oft zusammen eingesetzt, aber jedes kann ohne das andere bestehen.

Wann sollte ein SaaS-Unternehmen ereignisgesteuerte Automatisierung einsetzen?

Setzen Sie sie ein, wenn ein Geschäftsprozess von einem Fakt ausgehen soll, etwa einem abgeschlossenen Deal oder einer anstehenden Vertragsverlängerung, und mehrere Teams oder Systeme darauf reagieren müssen. Beginnen Sie mit einem kostspieligen Prozess und stellen Sie sicher, dass die Quelldaten zuvor abgestimmt sind.

Quellen