Event-Driven, Teil 5: Was bei Events wichtig ist – und was nicht

Events sind die Grundlage von Event-getriebener Architektur (Event-Driven Architecture, kurz EDA). Sie dokumentieren, was passiert ist, und sind damit die zentrale Wahrheit eines Systems. Doch gerade weil sie so zentral sind, ist es entscheidend, sie richtig zu gestalten und zu verarbeiten.

In diesem Teil werfen wir einen Blick auf Eigenschaften guter Events, häufige Stolperfallen – und auf technische Fragen, die zwar oft diskutiert werden, aber selten kritisch sind.

Zustandsübergänge statt Snapshots

Ein Event ist kein Snapshot. Es beschreibt nicht, wie etwas aussieht, sondern was passiert ist. Das ist ein fundamentaler Unterschied.

Beispiel: Nicht „Buch hat Status ‚verliehen'“, sondern „Buch wurde verliehen“. Der Unterschied mag subtil erscheinen, hat aber weitreichende Folgen:

• Ein Snapshot ist immer nur ein Bild des Jetzt, ein Event beschreibt den Weg dorthin.
• Snapshots überschreiben, Events bauen aufeinander auf.
• Snapshots verlieren Kontext, Events bewahren Historie.

Wer den Zustand eines Systems nur über Snapshots betrachtet, kann später nicht mehr nachvollziehen, wie dieser Zustand entstanden ist – und verliert so viel von dem, was Event-getriebene Systeme eigentlich auszeichnet.

Reihenfolge ist selten kritisch – aber Kontext schon

Ein häufiges Missverständnis: Die Reihenfolge von Events sei absolut entscheidend. In der Realität ist das meistens nicht der Fall.

Wenn man einen konkreten Zustand berechnen möchte („Wie ist der heutige Kontostand?“), braucht man die Events in der richtigen Reihenfolge, zumindest innerhalb des betroffenen Kontos. Aber bei reinen Reaktionen auf Events – etwa beim Erzeugen von Projections oder beim Triggern von Folgeaktionen – ist es oft egal, wann das Event eintrifft. Entscheidend ist, ob es überhaupt ankommt und ob es korrekt verarbeitet wird.

Das heißt nicht, dass Reihenfolge nie eine Rolle spielt. Aber wer sich zu sehr darauf versteift, macht Systeme unnötig fragil. Robuste Event-getriebene Systeme setzen auf:

• Idempotenz: Mehrfache Verarbeitung darf keinen Schaden anrichten.
• Vollständigkeit: Alle relevanten Events müssen verarbeitet werden.
• Korrekte Kontextgrenzen: Innerhalb eines Event-Streams kann Reihenfolge wichtig sein – darüber hinaus meist nicht.

Konsistenz ist eine Frage der Perspektive

In klassischen Systemen ist Konsistenz eine binäre Eigenschaft: Entweder ist das System konsistent oder nicht. In Event-getriebenen Systemen ist das differenzierter.

Statt globaler Transaktionen (Atomicity, Consistency, Isolation, Durability – ACID) gibt es lokale Konsistenz innerhalb von Aggregaten. Übergreifend wird mit schlussendlicher Konsistenz (Eventual Consistency) gearbeitet: Zustände dürfen kurzfristig auseinanderlaufen, solange sie sich mittelfristig wieder angleichen.

Das erfordert ein Umdenken, aber es bringt auch Vorteile:

• Systeme werden entkoppelt und robuster gegenüber Teilausfällen.
• Skalierung wird einfacher, weil nicht alles synchronisiert werden muss.
• Fachlich lässt sich oft gut begründen, warum leichte Verzögerungen akzeptabel sind.

Beispiel: Ein Benutzer hat ein Buch zurückgegeben. Die Rückgabe wird sofort im Ausleihsystem vermerkt. Dass die Mahngebühr erst fünf Sekunden später als „storniert“ markiert wird, ist in den allermeisten Fällen tolerierbar.

Was Events leisten müssen – und was nicht

Ein gutes Event

• ist eindeutig benannt, fachlich korrekt und stabil,
• dokumentiert eine Tatsache, keinen Wunsch oder Zwischenzustand,
• trägt nur die Information, die für die Reaktion nötig ist, und nicht den gesamten Systemzustand, und
• wird gespeichert, veröffentlicht und verarbeitet, aber nie geändert.

Was es nicht leisten muss:

• Es muss nicht alle Informationen enthalten, oft reicht stattdessen ein Verweis (zum Beispiel die ID).
• Es muss nicht für jede Zielgruppe perfekt sein, da Projections Informationen aufbereiten können.
• Es muss nicht „alles auf einmal“ ermöglichen – lieber kleine, gezielte Events als große, unübersichtliche Payloads.

Was kommt als Nächstes?

Im nächsten Teil steigen wir in ein praktisches Beispiel ein: eine Stadtbibliothek. Wir schauen uns an, wie man mit Events denkt, Abläufe modelliert und ein System Stück für Stück aufbaut – ohne sich in technischen Details zu verlieren.

(mai)