Was ist Event Driven Architecture? Einfach erklärt

Was ist Event Driven Architecture?

Event Driven Architecture (ereignisgesteuerte Architektur) ist ein Entwurfsansatz, bei dem Softwarekomponenten sich nicht gegenseitig direkt aufrufen, sondern Ereignisse veröffentlichen und auf Ereignisse reagieren. Zum Beispiel meldet der Bestelldienst "neue Bestellung". Lager, Rechnung und Benachrichtigung hören dann zu. Somit muss der Absender nicht wissen, wer zuhört.

Kurz gesagt: Komponenten sagen nicht mehr "mach das", sondern "das ist passiert". Danach entscheidet jeder Zuhörer selbst, was er tut. Daher macht dieser kleine Unterschied ein System deutlich leichter erweiterbar.

In diesem Beitrag beantworten wir die Frage, was ist Event Driven Architecture, auf Konzeptebene. Zudem sehen Sie keinen Codeblock, sondern nur die Logik, die Einsatzgebiete, die Vorteile und die Grenzen. Unser Team hält die Beispiele bewusst einfach, denn zuerst sollten Sie die Idee verstehen und erst danach die Details.

Was ist Event Driven Architecture, erklärt mit einer Bestelltafel in der Küche?

Zunächst stellen Sie sich eine Restaurantküche vor. Der Kellner nimmt eine Bestellung auf und geht dann zu jedem Koch, um zu sagen, was zu tun ist. Somit hängt die Küche vom Kellner ab. Außerdem muss er seine Routine ändern, sobald ein neuer Posten dazukommt. Also ist das der Stil des direkten Aufrufs.

Probieren Sie nun einen anderen Aufbau. Dann hängt der Kellner den Bestellzettel an eine Tafel in der Küche. Der Grillkoch sieht zum Beispiel seine Zeilen und legt los. Gleichzeitig nimmt der Patissier die Dessertzeilen. Dann sieht die Kasse denselben Zettel und bereitet die Rechnung vor.

Hier weiß der Kellner also nicht, wer den Zettel liest. Kommt ein neuer Posten dazu, bleibt seine Gewohnheit gleich. Deshalb entspricht die Tafel in der Software dem Broker. Der Zettel ist das Ereignis, also die schriftliche Aufzeichnung von etwas, das bereits passiert ist.

Allerdings hat jeder Vergleich Grenzen. In einem echten System kann ein Zettel verloren gehen, zweimal gelesen werden oder in falscher Reihenfolge ankommen. Daher betrachten die späteren Abschnitte genau diese Probleme.

Was ist der Unterschied zwischen Ereignis, Befehl und Nachricht?

Diese drei Begriffe werden oft verwechselt. Dennoch entscheidet der Unterschied darüber, ob ein Entwurf gesund bleibt.

• Ereignis (Event): Die Aufzeichnung von etwas, das schon passiert ist. Sie benennen es in der Vergangenheit, zum Beispiel "Zahlung eingegangen". Außerdem nehmen Sie es nicht zurück. Stattdessen veröffentlichen Sie ein neues Ereignis zur Korrektur.
• Befehl (Command): Eine Aufforderung, etwas zu tun, zum Beispiel "Rechnung erstellen". Dabei geht er meist an genau einen Empfänger.
• Nachricht (Message): Der allgemeine Umschlag, der beides transportieren kann. Ereignisse und Befehle reisen also beide als Nachrichten.

Denn Teams verstecken Befehle oft in Ereignisnamen. Ein "Rechnung angefordert Ereignis" ist dafür ein gutes Beispiel. In diesem Fall wartet der Absender auf etwas, und die lose Kopplung bricht still zusammen.

Eine einfache Regel hilft: Formulieren Sie das Ereignis als Meldung über das, was im eigenen Bereich des Absenders passiert ist. Zum Beispiel ist "Artikel verkauft" besser als "Lager aktualisieren". Das Erste meldet nämlich nur. Das Zweite verteilt Arbeit.

Was machen Producer, Broker und Consumer?

Zunächst ruht jedes ereignisgesteuerte System auf drei Rollen. Die Namen wechseln von Quelle zu Quelle, die Logik bleibt aber gleich. Außerdem können in einem kleinen System alle drei Rollen in einer einzigen Anwendung stecken.

• Producer (Erzeuger): Die Komponente, die bemerkt, dass etwas passiert ist, und es als Ereignis veröffentlicht. Zum Beispiel der Bestelldienst.
• Broker (auch Ereigniskanal oder Router): Der Teil, der Ereignisse annimmt, bei Bedarf speichert und an die richtige Stelle liefert.
• Consumer (Verbraucher): Die Komponente, die das Ereignis empfängt und ihre eigene Arbeit erledigt. Zum Beispiel der Lager- oder Benachrichtigungsdienst.

Außerdem beschreiben große Cloudanbieter dasselbe Trio. Das Microsoft Azure Architecture Center spricht von Producern, Consumern und Ereigniskanälen. AWS nutzt Producer, Router und Consumer.

Achten Sie deshalb bei der Toolwahl auf Rollen statt auf Produktnamen. Welche Komponente veröffentlicht, welche transportiert, welche reagiert? Wenn Sie diese drei Fragen beantworten können, lesen Sie also fast jedes Diagramm.

Wie funktioniert das Publish/Subscribe Modell?

Beim Publish/Subscribe veröffentlicht der Producer ein Ereignis in einem Thema (Topic) oder Kanal. Danach abonnieren die Consumer dieses Thema. Sobald ein Ereignis eintrifft, schickt der Broker dann jedem Abonnenten eine Kopie.

Deshalb kennt der Producer die Abonnenten nicht. Ebenso kennen sich die Abonnenten untereinander nicht. Denn jeder sieht seine eigene Kopie und arbeitet in seinem eigenen Tempo. Das ähnelt einem Newsletter: Der Herausgeber verschickt ihn und schaut nicht darauf, was jeder Leser damit tut.

Die Microsoft Dokumentation hebt ein Detail hervor. In diesem Modell behält der Broker das Ereignis nach der Zustellung nicht in einem dauerhaften Protokoll. Neue Abonnenten sehen daher keine früheren Ereignisse. Wenn Sie den Verlauf erneut lesen möchten, brauchen Sie also ein anderes Modell.

Zum Beispiel abonnieren Rechnungs-, Lager- und Benachrichtigungsdienst das Thema "neue Bestellung". Später möchte das Reporting dann dieselben Ereignisse. Sie fassen den Bestellcode nicht an, sondern legen nur ein neues Abonnement an.

Wie unterscheidet sich Event Streaming von einer Warteschlange und von Pub/Sub?

Beim Event Streaming schreibt der Broker die Ereignisse der Reihe nach in ein dauerhaftes Protokoll. Ein Consumer abonniert also nicht. Stattdessen liest er das Protokoll selbst und merkt sich seine eigene Position. Er kann also zurückspulen, und ein Nachzügler kann von Anfang an lesen.

Laut Microsoft Dokumentation unterstützt dieses Design die Wiederherstellung nach Fehlern, spät startende Consumer und die erneute Verarbeitung nach einer Fehlerbehebung. Zudem ist die Reihenfolge innerhalb einer Partition streng.

Eine Warteschlange arbeitet dagegen anders. Mehrere Consumer holen Nachrichten aus derselben Schlange, und ohne Fehler bekommt jede Nachricht genau einer von ihnen. Anders gesagt: Eine Warteschlange verteilt Arbeit, Pub/Sub verteilt Neuigkeiten.

• Nehmen Sie Pub/Sub, wenn mehrere Komponenten dasselbe Ereignis sehen müssen.
• Greifen Sie zur Warteschlange, wenn genau ein Worker jede Aufgabe übernehmen soll.
• Setzen Sie auf Event Streaming, wenn Sie den Verlauf später erneut abspielen möchten.

Wie unterscheidet sich Event Driven Architecture von Anfrage und Antwort?

Im klassischen Modell aus Anfrage und Antwort ruft eine Komponente eine andere auf und wartet auf das Ergebnis. Im ereignisgesteuerten Modell legt eine Komponente ein Ereignis ab und macht weiter. Deshalb stellt die folgende Tabelle beide nebeneinander.

Fragen Sie nicht, wer gewinnt. Denn beide leben im selben System. Zum Beispiel nutzen Sie Anfrage und Antwort für die Produktseite und überlassen die Arbeit nach der Bestellung den Ereignissen.

Wie läuft eine Onlineshop Bestellung in einem ereignisgesteuerten System ab?

Der folgende Ablauf ist ein Beispielszenario. Daher beschreibt er keinen echten Kunden und kein gemessenes Ergebnis. Stellen Sie sich also einen kleinen Onlineshop vor, der eine Bestellung erhält.

1. Zuerst bestätigt der Kunde die Bestellung. Dann speichert der Bestelldienst sie und veröffentlicht das Ereignis "neue Bestellung".
2. Danach empfängt der Lagerdienst das Ereignis, reserviert die Artikel und veröffentlicht "Bestand reserviert".
3. Als Nächstes versucht der Zahlungsdienst die Abbuchung. Gelingt sie, dann veröffentlicht er "Zahlung eingegangen".
4. Anschließend schickt der Benachrichtigungsdienst eine E-Mail zur Bestätigung.
5. Schließlich sehen Versand und Rechnungsdienst "Zahlung eingegangen" und starten ihre eigene Arbeit.

Schlägt die Zahlung fehl, veröffentlicht der Zahlungsdienst "Zahlung fehlgeschlagen". Somit sieht der Lagerdienst das Ereignis und gibt die reservierten Artikel wieder frei. Die Microsoft Dokumentation nennt diese Idee eine Ausgleichstransaktion (Compensating Transaction).

Beachten Sie zudem, dass keine einzelne Funktion die ganze Bestellung besitzt. Stattdessen erledigen kleine, unabhängige Reaktionen die Arbeit, sodass Sie jedes Teil einzeln testen. Für die Zahlungsseite hilft unser Beitrag zu Zahlungsanbietern für Onlineshops.

Warum sorgt Event Driven Architecture für lose Kopplung?

Lose Kopplung bedeutet also, dass Sie eine Komponente ändern können, ohne die anderen anzufassen. Der Producer veröffentlicht nur das Ereignis. Denn wie viele Consumer es gibt, wie sie heißen und was sie tun, weiß er nicht.

Die Microsoft Dokumentation fasst es so zusammen: Es gibt keine Punkt zu Punkt Integrationen, und neue Consumer lassen sich hinzufügen, ohne Producer oder andere Consumer zu ändern. Daher entlastet das Teams, die parallel arbeiten, spürbar.

Ein Team kann also einen Consumer ergänzen, ohne auf den Release Kalender eines anderen Teams zu warten. Genau das spricht die meisten Leser an, die wissen wollen, was ist Event Driven Architecture im Alltag.

Allerdings gibt es keine Kopplung von null. Denn das Ereignisformat ist ein gemeinsamer Vertrag. Ändert der Producer ein Feld, können Consumer brechen, deshalb brauchen Sie Schemaversionen. Die Idee der Unabhängigkeit gibt es auch im Frontend, wie unser Beitrag zu Micro Frontends zeigt. Außerdem schalten Sie mit einem Feature Flag einen neuen Consumer sicher frei.

Welche Vorteile bringt das bei Skalierung und Ausfallsicherheit?

Die AWS Dokumentation sagt, dass Producer und Consumer unabhängig skalieren, sich aktualisieren und ausliefern lassen. Im Alltag zeigt sich das ganz konkret.

• Plötzliche Last: Bei einer Aktion stauen sich Bestellungen im Broker. Die Consumer arbeiten in ihrem Tempo, deshalb bricht das System nicht zusammen. Somit wird aus einer Spitze eine kurze Verzögerung statt eines Ausfalls.
• Fehlerisolierung: Fällt der Benachrichtigungsdienst aus, läuft die Bestellannahme weiter. Die Ereignisse warten und gehen weiter, sobald der Dienst zurück ist.
• Unabhängige Skalierung: Sie ergänzen Instanzen nur beim Consumer, der gerade ausgelastet ist.
• Weniger Abfragen: Consumer reagieren, wenn ein Ereignis eintrifft. AWS beschreibt das als Verzicht auf Bezahlung für ständiges Abfragen.

Der Vorteil stellt sich allerdings nicht von selbst ein. Denn der Broker ist ebenfalls eine Komponente, und Sie müssen ihn betreiben. Denken Sie außerdem an Hilfsmittel auf der Leseseite wie Caches. Unser Vergleich von Redis und Memcached behandelt diese Seite.

Was ist CloudEvents und warum vereinheitlicht es Ereignisse?

CloudEvents ist eine herstellerunabhängige Spezifikation, die das Format von Ereignisdaten beschreibt. Außerdem liegt sie unter dem Dach der CNCF (Cloud Native Computing Foundation). Ihr Ziel ist, dass verschiedene Dienste und Werkzeuge Ereignisse mit einem gemeinsamen Umschlag beschreiben.

Die offizielle Spezifikation nennt vier Pflichtattribute: id, source, specversion und type. Mit anderen Worten trägt jedes Ereignis eine Kennung, eine Quelle, eine Version und einen Typ.

Ein weiteres Detail ist wichtig. Denn die Spezifikation legt keine Zustellgarantien fest. Die hängen vom Protokoll und vom Werkzeug ab. Der Satz "wir nutzen CloudEvents, also gehen keine Ereignisse verloren" ist deshalb falsch.

In der Praxis hilft der Standard auf zwei Arten. Erstens gibt er verschiedenen Systemen eine gemeinsame Sprache. Zweitens hilft das Feld id, ein wiederholtes Ereignis zu erkennen.

Wie viele Informationen sollte ein Ereignis transportieren?

Eine häufige Entwurfsfrage lautet, ob das Ereignis alles enthalten soll oder nur einen Schlüssel. Die Microsoft Dokumentation beschreibt beide Ansätze.

• Alle Daten mitgeben: Der Consumer arbeitet, ohne jemanden zu fragen. Andererseits wachsen die Ereignisse, Verträge werden komplex, und veraltete Kopien können nach Änderungen zu Inkonsistenz führen.
• Nur den Schlüssel mitgeben: Der Consumer holt den Rest aus der Quelle. Die Daten kommen aus einer Stelle, dafür erhält die Quelle viele Abfragen.

Die richtige Wahl hängt davon ab, was die Consumer brauchen. Daher können Sie beides sogar in einem System mischen. Eine Regel sollten Sie dennoch festhalten: Legen Sie nicht mehr sensible Daten in ein Ereignis als nötig.

Denn viele Komponenten sehen ein Ereignis, auch solche, die es nicht brauchen. Statt persönlicher Daten, Passwörter oder Zahlungsdetails transportieren Sie deshalb nur einen Verweis darauf.

Was bedeutet eventuelle Konsistenz im Alltag?

Eventuelle Konsistenz heißt, dass Daten nach einer kurzen Verzögerung überall gleich sind, nicht im selben Augenblick. Meldet ein Producer eine Änderung, verarbeiten die Consumer sie in ihrem eigenen Tempo. Dazwischen öffnet sich dann ein kleines Zeitfenster.

Zum Beispiel gibt ein Kunde eine Bestellung auf. Der Bestellbildschirm zeigt sofort "Wir haben Ihre Bestellung erhalten". Der Lagerbestand sinkt jedoch einen Moment später. In dieser Lücke können also zwei Systeme Unterschiedliches sagen.

Das ist ein bewusster Kompromiss und kein Fehler. Die Microsoft Dokumentation sagt, dass Architekten in manchen Abläufen eventuelle Konsistenz akzeptieren, um die Verfügbarkeit zu bevorzugen. Dennoch passt sie nicht zu jedem Ablauf.

• Zunächst zeigen Sie Zwischenstatus im Interface an.
• Entwerfen Sie außerdem Leseansichten, die leicht veraltete Daten vertragen.
• Lassen Sie schließlich Vorgänge mit Bedarf an sofortiger Genauigkeit, etwa eine Kontostandsprüfung, bei einer maßgeblichen Quelle.

Warum kommen Ereignisse doppelt an, und warum ist Idempotenz wichtig?

Was macht ein Broker, wenn ein Consumer ein Ereignis verarbeitet, aber nicht bestätigt? Viele Systeme stellen es erneut zu, damit nichts verloren geht. Deshalb kann dasselbe Ereignis zweimal ankommen. Das genaue Verhalten hängt vom Werkzeug ab, also prüfen Sie dessen Dokumentation.

Genau hier beginnt deshalb das Problem. Verarbeitet der Rechnungsdienst dasselbe Ereignis "Zahlung eingegangen" zweimal, stellt er zwei Rechnungen aus. Verarbeitet der Lagerdienst es zweimal, sinkt somit der Bestand zu stark.

Die Lösung sind daher idempotente Consumer. Eine idempotente Operation hinterlässt dasselbe Ergebnis, egal ob sie einmal oder mehrfach läuft. Praktisch speichern Sie die id jedes Ereignisses und überspringen Ereignisse, die Sie schon kennen.

Dieses Thema behandeln wir ausführlich in einem Schwesterbeitrag. Lesen Sie dazu was Idempotenz ist und wie Sie doppelte Anfragen in Ihrer API verhindern, denn dort finden Sie praktische Muster gegen wiederholte Anfragen.

Warum gerät die Reihenfolge durcheinander, und wie steuern Sie sie?

Für Ausfallsicherheit läuft jeder Consumer in mehreren Kopien. Zudem verarbeiten diese Kopien Ereignisse gleichzeitig und unterschiedlich schnell. Die Reihenfolge "erst A, dann B" bleibt deshalb nicht automatisch erhalten.

Auch die Fehlerbehandlung kann die Reihenfolge verwirren. Laut Microsoft Dokumentation kommt ein Ereignis außer der Reihe an, wenn ein Fehlerbehandler es erneut einspielt.

Wenn die Reihenfolge zählt, bedenken Sie diese Schritte:

• Leiten Sie Ereignisse zur selben Entität in dieselbe Partition, denn innerhalb einer Partition bleibt die Reihenfolge fest.
• Außerdem fügen Sie eine Versionsnummer oder Sequenz hinzu, damit ein Consumer ein zu spät eintreffendes Ereignis überspringt.
• Entwerfen Sie den Ablauf nach Möglichkeit so, dass er ohne Reihenfolge funktioniert. Transportieren Sie zum Beispiel "der Zustand ist jetzt so" statt nur "das hat sich geändert".
• Halten Sie Abläufe, die wirklich eine Reihenfolge brauchen, getrennt und dokumentieren Sie sie.

Warum sind Fehlersuche und Nachverfolgung schwieriger?

In einer klassischen Anwendung folgen Sie einem Fehler über den Aufrufstapel. In einem ereignisgesteuerten System läuft ein Geschäftsvorgang dagegen über viele Producer, Kanäle und Consumer. Es gibt daher keinen gemeinsamen Aufrufkontext.

Die Microsoft Dokumentation empfiehlt, in jedes Ereignis eine Korrelationskennung zu legen. Damit fügen Sie dann Logzeilen zu einer Geschichte zusammen. Außerdem kostet es viel weniger, das von Anfang an einzuplanen, als es später nachzurüsten.

• Tragen Sie in jedem Ereignis eine Korrelationskennung und schreiben Sie sie in jede Logzeile.
• Richten Sie eine Dead Letter Queue für fehlgeschlagene Ereignisse ein, damit Sie sie prüfen können, statt sie zu verlieren.
• Beobachten Sie außerdem Verzögerung und Fehleranzahl pro Consumer.
• Planen Sie Tests über den gesamten Ablauf bewusst, denn verkettete Abläufe verstecken Probleme in einfachen Tests.

Die AWS Dokumentation ergänzt eine Erinnerung: Den Ablauf verfolgen Sie über Monitoring und nicht durch das Lesen von Code.

Broker oder Mediator: Welche Topologie wählen Sie?

Die Microsoft Dokumentation beschreibt zwei Haupttopologien. Die Wahl hängt also davon ab, wie komplex der Ablauf ist und wie viel Kontrolle Sie brauchen.

In der Broker Topologie streuen die Komponenten Ereignisse ins ganze System. Eine andere Komponente handelt dann oder ignoriert das Ereignis. Es gibt keine zentrale Koordination, deshalb bleibt alles flexibel. Allerdings fehlt ein eingebauter Mechanismus, der einen halb abgebrochenen Ablauf mit mehreren Schritten neu startet.

In der Mediator Topologie steuert ein Vermittler den Ereignisfluss. Er hält den Zustand und übernimmt Fehlerbehandlung und Neustarts. Daher bringt das mehr Kontrolle. Andererseits erhöht es die Kopplung, und der Mediator kann zum Engpass werden.

• Beginnen Sie mit der Broker Topologie, wenn der Ablauf einfach ist und die Komponenten eigenständig sind.
• Denken Sie an einen Mediator bei Abläufen mit mehreren Schritten, die eventuell zurückgerollt werden müssen.
• Sie dürfen beides in einem System für unterschiedliche Abläufe nutzen, wenn es passt.

Ist Event Driven Architecture dasselbe wie Microservices, Serverless oder Webhooks?

Nein, das sind verschiedene Dinge, aber sie tauchen in denselben Gesprächen auf. Denn jeder Begriff beantwortet eine andere Frage. Deshalb fasst die folgende Tabelle die Trennung zusammen.

Für die Wahl von Sprache und Framework auf der Dienstseite lesen Sie unseren Vergleich Python und Go für Backend Microservices. Zu Funktionen, die bei Ereignissen starten, und zum Kaltstartproblem lesen Sie was Serverless und Cold Start bedeuten.

Wo begegnet Ihnen Event Driven Architecture in der Praxis?

Dieser Stil gehört also nicht nur großen Technikkonzernen. Auch kleine und mittlere Unternehmen nutzen ereignisbasierte Systeme, ohne es zu merken. Hier sind einige bekannte Beispielszenarien.

• Onlineshop: Nach einer Bestellung laufen Lager, Rechnung, Versand und Benachrichtigung als getrennte Reaktionen.
• Registrierung: Ein Ereignis für ein neues Konto löst unabhängig voneinander eine E-Mail zur Begrüßung, einen Kundendatensatz und das Reporting aus.
• Gerätedaten: Die Azure Dokumentation nennt große Datenmengen von Geräten wie Sensoren als typischen Einsatz.
• Integrationen: Buchhaltung, CRM und Lagersoftware hören auf dasselbe Ereignis und bleiben aktuell, ohne dass jemand von Hand kopiert.

Der gemeinsame Faden ist einfach: Etwas passiert, und mehrere Parteien antworten darauf mit ihrer eigenen Arbeit. Sieht Ihr Ablauf nicht so aus, genügt daher vermutlich ein einfacherer Entwurf.

Wie ändern Sie ein Ereignisschema im Lauf der Zeit?

Producer und Consumer gehen zu unterschiedlichen Zeiten live. Sie können daher nicht alle gleichzeitig aktualisieren. Ändert ein Producer die Struktur eines Ereignisses, kann ein Consumer, der die neue Form nicht kennt, brechen.

Die Microsoft Dokumentation rät, früh eine Strategie für Schemaversionen festzulegen. Außerdem sollen Consumer mit Versionen umgehen, die sie nicht kennen. Toleranz gehört also zum Entwurf.

• Löschen Sie alte Felder nicht sofort. Fügen Sie zuerst das neue Feld hinzu und lassen Sie eine Übergangszeit zu.
• Tragen Sie die Schemaversion im Ereignis selbst.
• Sorgen Sie dafür, dass Consumer unbekannte Felder ignorieren.
• Kündigen Sie Versionsänderungen den Teams mit einer kurzen Änderungsnotiz an.

Diese Disziplin wirkt vielleicht trocken. Dennoch ist der Ereignisvertrag der langlebigste Teil der Architektur, deshalb braucht er die meiste Pflege.

Wann ist Event Driven Architecture die falsche Wahl?

Allerdings braucht nicht jedes System sie. Die Microsoft Dokumentation sagt das deutlich. Erfüllen einfache Abläufe aus Anfrage und Antwort Ihre Anforderungen an die Latenz bereits, lässt sich der Aufwand für einen Broker und für eventuelle Konsistenz kaum rechtfertigen.

• Für eine kleine Unternehmenswebsite oder eine App eines einzelnen Teams reichen direkte Aufrufe oft aus.
• Brauchen Dienste strenge, sofortige Konsistenz, arbeitet eventuelle Konsistenz gegen Sie.
• Hat Ihr Team keine Erfahrung mit verteilten asynchronen Systemen, bremst die Lernkurve die Liefertermine.

Die Frage, was ist Event Driven Architecture, sollte nie mit "setzen wir überall ein" enden. Die bessere Frage lautet, welches Bedürfnis Sie lösen. Der Stil ergibt zum Beispiel Sinn, wenn mehrere Komponenten auf ein Ereignis reagieren, wenn die Last bei Aktionen schwankt oder wenn Teams unabhängig vorankommen wollen.

Möchten Sie die Entscheidung gemeinsam abwägen, schauen Sie sich unsere individuelle Softwareentwicklung an. Wir halten die Architektur so einfach, wie es das Bedürfnis zulässt.

Wie sieht die Checkliste für Unternehmen und Entwickler vor dem Start aus?

Die zwei Listen unten sammeln die Punkte für ein Entwurfsgespräch. Zunächst die Unternehmensseite. Diese Fragen sollte eine Geschäftsführerin oder ein Fachverantwortlicher beantworten, nicht ein Entwickler.

• Welche Prozesse gewinnen wirklich durch sofortige Reaktion?
• Welche Daten müssen in jedem Moment exakt stimmen?
• Wer greift ein, wenn ein Ereignis schiefgeht, und über welche Ansicht?
• Wer verantwortet den Broker und das Monitoring?

Als Nächstes die Entwicklerseite. Das Team sollte diese Antworten klären, bevor die Programmierung beginnt.

• Haben Sie Ereignisse in der Vergangenheitsform und in einer einheitlichen Fachsprache benannt?
• Trägt jedes Ereignis eine eindeutige ID, Quelle, Typ und Schemaversion?
• Sind Consumer idempotent, sodass ein wiederholtes Ereignis sicher übersprungen wird?
• Stehen Korrelationskennung, Dead Letter Queue und Alarme bereit?
• Gibt es für Abläufe mit Reihenfolgebedarf schriftliche Regeln?
• Enthalten Ereignisse nur Verweise statt sensibler Daten?

Mit welchen Schritten starten Sie klein?

Deshalb versuchen Sie nicht, das ganze System auf einmal umzustellen. Mit einem kleinen, messbaren Ablauf zu beginnen ist deutlich sicherer.

1. Zuerst wählen Sie einen Ablauf, etwa den Versand einer Benachrichtigung nach der Bestellung.
2. Benennen Sie seine Ereignisse in der Vergangenheitsform und schreiben Sie das Schema auf.
3. Dann fügen Sie neben dem vorhandenen Code einen Schritt hinzu, der das Ereignis veröffentlicht. Entfernen Sie den alten Weg noch nicht.
4. Schreiben Sie den ersten Consumer idempotent und verfolgen Sie ihn mit einer Korrelationskennung.
5. Beobachten Sie ihn einige Wochen und prüfen Sie dann Fehler und Verzögerungen.
6. Entfernen Sie den alten direkten Aufruf, sobald Sie Vertrauen haben, und gehen Sie zum nächsten Ablauf.

So passt die Architektur zum Lerntempo Ihres Teams. Außerdem ist der Rückweg leicht, falls etwas schiefgeht.

Kurz gesagt: Was ist Event Driven Architecture und wem nützt sie?

Kurz gesagt, was ist Event Driven Architecture? Komponenten melden, was passiert ist, statt Befehle zu geben, und die Interessierten erledigen ihre eigene Arbeit. Das bringt lose Kopplung, unabhängige Skalierung und flexibles Wachstum.

Im Gegenzug müssen Sie also eventuelle Konsistenz, Reihenfolge, wiederholte Zustellung und schwierigere Nachverfolgung im Griff haben. Die Vorteile sind also nicht kostenlos. Wählen Sie zuerst das Bedürfnis und danach das Werkzeug.

Bevor Sie entscheiden, lohnt der Blick in die Quellen: das Azure Architecture Center, AWS und das CloudEvents Projekt enthalten aktuelle Details. Prüfen Sie den aktuellen Stand von Anbieterfunktionen immer in der offiziellen Dokumentation.