Ereignisgesteuerte Architektur: Broker, Mediatoren und Event-Streams

Definition: auf Geschehnisse reagieren

In einer ereignisgesteuerten Architektur (EDA) kommunizieren Komponenten, indem sie Ereignisse erzeugen und auf sie reagieren: Aufzeichnungen von Tatsachen, die im Geschäft eingetreten sind, etwa eine Bestellung wurde aufgegeben oder ein Kurier wurde zugewiesen. Die Komponente, die ein Ereignis veröffentlicht, ruft die Komponenten, die darauf reagieren, nicht auf und weiß meist nicht einmal, dass es sie gibt. Ein Message Broker transportiert Ereignisse von Produzenten zu Consumern, hält sie vor, während Consumer beschäftigt oder ausgefallen sind, und erlaubt es, neue Consumer hinzuzufügen, ohne den Produzenten zu ändern.

Ereignisgesteuerte Designs sind nicht neu: Grafische Benutzeroberflächen, Betriebssysteme und Handelssysteme arbeiten seit Jahrzehnten so, und Enterprise-Messaging-Produkte sind älter als das Web. Was sich in den 2010er-Jahren änderte, waren Größenordnung und Dauerhaftigkeit. Logbasierte Broker wie Apache Kafka, entstanden bei LinkedIn und 2011 als Open Source veröffentlicht, machten es praktikabel, jedes Geschäftsereignis tage- oder jahrelang aufzubewahren und erneut abzuspielen. EDA kann der Hauptstil eines Systems sein oder, häufiger, die Art, wie die Services eines Microservice- oder servicebasierten Systems miteinander sprechen.

Ereignisse, Commands und Nachrichten

Drei Wörter werden oft unscharf verwendet, und der Unterschied ist wichtig. Eine Nachricht ist der Umschlag: beliebige Daten, die von einem Programm über einen Kanal an ein anderes gesendet werden. Was die Nachricht transportiert, kann ein Ereignis sein (eine Tatsache, in der Vergangenheitsform benannt), ein Command (eine Anfrage an einen Handler, als Anweisung benannt) oder eine Abfrage und ihre Antwort. Gregor Hohpe und Bobby Woolf haben diese Nachrichtentypen und die Kanäle, die sie transportieren, in Enterprise Integration Patterns (2003) katalogisiert, und ihr Vokabular ist bis heute der Standard.

Nachrichten laufen über zwei Arten von Kanälen. Eine Queue stellt jede Nachricht einem ihrer Consumer zu, was zu Commands und zur Arbeitsverteilung passt. Ein Topic stellt jedem Subscriber eine Kopie jeder Nachricht zu; das ist Publish-Subscribe (Pub-Sub) und passt zu Ereignissen. Ein Design, das OrderPlaced an ein Topic sendet, lässt Zahlungen, Restaurant, Benachrichtigungen und Analytics reagieren, jeden in seinem eigenen Tempo; einen Betrugserkennungsservice im nächsten Jahr hinzuzufügen, bedeutet ein neues Abonnement und keine Änderung an den Bestellungen.

Broker-Topologie und Mediator-Topologie

Richards und Ford beschreiben zwei Topologien für ereignisgesteuerte Systeme. In der Broker-Topologie gibt es keinen zentralen Koordinator. Ein auslösendes Ereignis wird veröffentlicht; jeder interessierte Prozessor reagiert und kann weitere Ereignisse veröffentlichen, auf die wiederum andere reagieren. Der Ablauf existiert nur als Summe dieser Reaktionen. Das ist Choreografie: Wie Tänzer, von denen jeder seine eigenen Schritte kennt, lenkt niemand das Ganze.

In der Mediator-Topologie empfängt ein Event-Mediator das auslösende Ereignis und steuert den Ablauf, indem er Commands in einer festgelegten Reihenfolge an Prozessoren sendet und auf ihre Antworten reagiert. Das ist Orchestrierung: Ein Dirigent kennt die Partitur. Mediatoren reichen von einem einfachen Service mit Zustandsautomat bis zu einer Workflow-Engine wie Temporal, AWS Step Functions oder einer BPMN-Engine.

Die meisten realen Systeme mischen beides: Choreografie zwischen Bounded Contexts (die Bestellungen verkünden Tatsachen und kümmern sich nicht darum, wer zuhört) und Orchestrierung innerhalb eines Kontexts, wo ein mehrstufiger Prozess einen klaren Verantwortlichen braucht.

Vier Arten, Ereignisse zu nutzen

In einem Artikel von 2017 wies Martin Fowler darauf hin, dass „ereignisgesteuert“ für mindestens vier ganz verschiedene Muster verwendet wird und dass Gespräche schiefgehen, wenn Menschen verschiedene davon meinen. Sie auseinanderzuhalten, ist eine der nützlichsten Gewohnheiten, die ein Architekt haben kann.

Event Notification und Event-Carried State Transfer betreffen die Kommunikation zwischen Services und gehören in dieses Kapitel. Event-Sourcing und CQRS betreffen die Art, wie ein Service seine Daten speichert; sie werden oft mit EDA kombiniert, sind aber unabhängige Entscheidungen und werden in Kapitel 7 behandelt.

Event-Streams und Logs: wie Kafka funktioniert

Herkömmliche Message Queues löschen eine Nachricht, sobald ein Consumer sie bestätigt. Ein logbasierter Broker wie Apache Kafka speichert Ereignisse stattdessen in einem nur anfügbaren Log und bewahrt sie für eine konfigurierte Aufbewahrungsdauer (oder für immer) auf, unabhängig davon, ob sie gelesen wurden. Aus diesem Design folgen mehrere Dinge, und sie erklären sowohl Kafkas Stärken als auch seine Fallstricke.

Ein Topic ist in Partitionen aufgeteilt, von denen jede ein geordnetes Log ist, das über Broker hinweg gespeichert und repliziert wird. Ein Produzent wählt die Partition, normalerweise durch Hashing des Ereignisschlüssels, sodass alle Ereignisse mit demselben Schlüssel (etwa derselben Bestell-ID) in derselben Partition landen. Jedes Ereignis in einer Partition hat eine fortlaufende Position, seinen Offset. Consumer holen Ereignisse ab und speichern den Offset, den sie erreicht haben; sie können auch zurückspulen und erneut abspielen.

Consumer treten einer Consumer Group bei. Innerhalb einer Gruppe wird jede Partition zu jedem Zeitpunkt von genau einem Consumer gelesen, sodass sich die Gruppe die Arbeit teilt; verschiedene Gruppen lesen unabhängig voneinander, jede mit ihren eigenen Offsets, und so wird Pub-Sub erreicht. Die Zahl der Partitionen begrenzt daher die Parallelität einer Gruppe: Ein Topic mit 12 Partitionen kann höchstens 12 Consumer einer Gruppe beschäftigen. (Kafka 4.2, 2026 veröffentlicht, hat Share Groups als Queue-ähnliche Alternative hinzugefügt: Mehrere Consumer können sich eine Partition teilen und Nachrichten einzeln bestätigen, die Reihenfolge innerhalb der Partition bleibt dann aber nicht erhalten. Dieser Abschnitt beschreibt klassische Consumer Groups.)

Kafka garantiert die Reihenfolge nur innerhalb einer Partition. Ereignisse zu einer Bestellung kommen in der Reihenfolge an, in der sie geschrieben wurden, wenn sie einen Schlüssel teilen; Ereignisse zu verschiedenen Bestellungen in verschiedenen Partitionen haben zueinander keine definierte Reihenfolge. Designs, die eine globale Reihenfolge brauchen, müssen eine einzige Partition verwenden (und damit auf Parallelität verzichten) oder, besser, so umgestaltet werden, dass nur die Reihenfolge pro Entität zählt.

Zustellgarantien und was „exactly once“ wirklich bedeutet

Weil Netzwerke und Prozesse ausfallen (Abschnitt 6.1), müssen ein Broker und seine Clients festlegen, was geschieht, wenn nach einem Absturz oder Timeout unklar ist, ob eine Nachricht verarbeitet wurde. Es gibt drei mögliche Garantien, und welche gilt, hängt davon ab, wann Bestätigungen und Offsets gespeichert werden.

„Exactly once“ muss sorgfältig definiert werden. Eine Exactly-once-Zustellung über ein unzuverlässiges Netzwerk ist im Allgemeinen nicht erreichbar: Ein Sender, der keine Bestätigung erhält, kann nicht wissen, ob er erneut senden soll. Was Systeme bieten können, ist eine Exactly-once-Wirkung innerhalb einer definierten Grenze. Kafka zum Beispiel bietet seit Version 0.11 (2017) einen idempotenten Produzenten und Transaktionen, sodass ein Lesen-Verarbeiten-Schreiben-Zyklus von Kafka-Topics zu Kafka-Topics seine Ausgabe und seine Consumer-Offsets atomar committet. Diese Garantie endet an der Grenze von Kafka. Belastet der Consumer eine Karte, sendet er eine E-Mail oder schreibt er in eine andere Datenbank, führt ein Absturz zwischen dieser Aktion und dem Offset-Commit dazu, dass die Aktion wiederholt wird, es sei denn, der Consumer selbst ist idempotent oder speichert seine Offsets in derselben Transaktion wie seine Ergebnisse.

Die praktische Regel für Architekten ist daher einfach: Gehen Sie von At-least-once-Zustellung aus und machen Sie jeden Consumer zu einem idempotenten Consumer. Geben Sie jedem Ereignis eine eindeutige Kennung; speichern Sie im Consumer die verarbeiteten Kennungen in derselben lokalen Transaktion wie die Zustandsänderung, und überspringen Sie jedes bereits gespeicherte Ereignis. Machen Sie die Operation nach Möglichkeit auch von Natur aus idempotent, etwa „Status auf PAID setzen, wenn er AWAITING_PAYMENT ist“ statt „eine Zahlung hinzufügen“.

# Idempotent consumer: processing the same event twice has the effect of once
def handle_payment_authorised(event, db):
    with db.transaction():                       # one local ACID transaction
        inserted = db.execute(
            "INSERT INTO processed_events (event_id) VALUES (%s) "
            "ON CONFLICT (event_id) DO NOTHING",
            [event["event_id"]],
        ).rowcount
        if inserted == 0:
            return                               # seen before: do nothing
        db.execute(
            "UPDATE orders SET status = 'PAID' WHERE order_id = %s "
            "AND status = 'AWAITING_PAYMENT'",
            [event["order_id"]],
        )
    # commit the broker offset only after the transaction has committed

Ereignisschemas und Versionierung

Sobald andere Teams ein Ereignis konsumieren, ist seine Struktur ein veröffentlichter Vertrag, genau wie eine API, und er hält länger: Bei einem logbasierten Broker können Consumer Ereignisse lesen, die vor Monaten geschrieben wurden. Ein gutes Ereignis hat eine eindeutige Kennung, einen Typ, eine Schemaversion, den Zeitpunkt seines Eintretens, die Kennungen der beteiligten Entitäten und die Geschäftsdaten, die Consumer brauchen. Geldbeträge werden in der kleinsten Währungseinheit mit Angabe der Währung gespeichert, nie als Gleitkommazahl (Kapitel 0).

{
  "event_id": "9f1c2e7a-4b0d-4e55-9a51-0c3d8f2b6a10",
  "type": "OrderPlaced",
  "schema_version": 2,
  "occurred_at": "2026-10-22T18:42:07Z",
  "order_id": "ord-4711",
  "customer_id": "cus-208",
  "restaurant_id": "res-31",
  "items": [{"dish_id": "d-5", "qty": 2, "price_minor": 1150}],
  "total_minor": 2450,
  "currency": "GBP"
}

Schemas sollten sich abwärtskompatibel weiterentwickeln: optionale Felder hinzufügen, Felder nie ohne neue Version entfernen, umbenennen oder in ihrer Bedeutung ändern und einen Feldnamen nie für etwas anderes wiederverwenden. Viele Teams setzen das mit einem Schemaformat wie Avro, Protocol Buffers oder JSON Schema und einer Schema Registry durch, die inkompatible Änderungen beim Veröffentlichen zurückweist. Die CloudEvents-Spezifikation, ein graduiertes Projekt der Cloud Native Computing Foundation, standardisiert die gemeinsamen Umschlagattribute wie id, source, type und time. Kompatibilitätsmodi und Migrationstechniken werden unter Schemaevolution behandelt.

Fehlerbehandlung: Wiederholungen, Poison Messages und Dead Letter Queues

Consumer scheitern aus zwei sehr verschiedenen Gründen, und diese brauchen eine unterschiedliche Behandlung. Vorübergehende Fehler, etwa eine kurzzeitig nicht verfügbare Datenbank oder ein Timeout beim Aufruf eines anderen Service, gelingen meist beim erneuten Versuch; wiederholen Sie einige Male mit exponentiellem Backoff und Jitter (zunehmenden, zufällig gestreuten Verzögerungen), damit eine angeschlagene Abhängigkeit nicht überlastet wird. Dauerhafte Fehler, etwa ein fehlerhaft aufgebautes Ereignis oder eines, das gegen eine Geschäftsregel verstößt, scheitern jedes Mal. Eine solche „Poison Message“ darf den Consumer nicht für immer blockieren, was auf einem partitionierten Log jedes spätere Ereignis in dieser Partition aufhalten würde.

Die Standardlösung ist eine Dead Letter Queue (DLQ): Nach einer festgelegten Zahl von Versuchen wird die Nachricht in einen separaten Kanal verschoben, der Fehler wird festgehalten, und der Consumer macht weiter. Eine DLQ ist nur nützlich, wenn jemand sie beobachtet: Alarmieren Sie bei ihrer Größe, geben Sie einem benannten Team die Verantwortung, stellen Sie Werkzeuge bereit, um Nachrichten zu untersuchen, zu korrigieren und erneut abzuspielen, und legen Sie vorab fest, welche Reihenfolgegarantien verloren gehen, wenn eine Nachricht verspätet erneut abgespielt wird. Manche Teams schalten vor der DLQ ein oder mehrere Retry-Topics mit längeren Verzögerungen dazwischen.

Wann man sie einsetzt, und häufige Fehler

Ereignisgesteuerte Architektur passt, wenn viele Teile eines Geschäfts auf dieselben Tatsachen reagieren müssen, wenn Arbeit erledigt werden kann, nachdem die Anfrage des Benutzers beantwortet ist, wenn die Last schubweise kommt und geglättet werden muss und wenn mit der Zeit neue Consumer zu erwarten sind. Weniger gut passt sie, wenn ein Benutzer eine sofortige, endgültige Antwort braucht, die von mehreren Services abhängt (obwohl ein synchroner Aufruf für die Antwort plus Ereignisse für die Folgeschritte ein gängiger Hybrid ist), oder wenn starke Konsistenz über Services hinweg erforderlich ist.