Events und Zeitstempel: Wann ist etwas wirklich passiert?

Wer mit Events arbeitet, stößt früher oder später auf eine vermeintlich simple Frage: Wann ist etwas eigentlich passiert? Und die Antwort scheint naheliegend, denn jedes Event bringt schließlich einen Zeitstempel mit. Bei CloudEvents ist das etwa das time-Feld, das viele Systeme automatisch setzen, wenn ein Event gespeichert wird. Es liegt nahe, diesen Zeitstempel für Geschäftslogik zu verwenden, er ist ja schließlich da. Doch genau das führt zu subtilen Fehlern und falschen Annahmen.

the next big thing – Golo Roden

Golo Roden ist Gründer und CTO von the native web GmbH. Er beschäftigt sich mit der Konzeption und Entwicklung von Web- und Cloud-Anwendungen sowie -APIs, mit einem Schwerpunkt auf Event-getriebenen und Service-basierten verteilten Architekturen. Sein Leitsatz lautet, dass Softwareentwicklung kein Selbstzweck ist, sondern immer einer zugrundeliegenden Fachlichkeit folgen muss.

Das Problem: Wann wurde das Buch ausgeliehen?

Nehmen wir ein klassisches Bibliotheksbeispiel. Ein Leser leiht ein Buch aus, und das System erzeugt folgendes Event:

{
"source": "https://library.thenativeweb.io",
"subject": "/books/42",
"type": "io.thenativeweb.library.book-borrowed",
"data": {
"borrowedBy": "/readers/23",
"borrowedUntil": "2026-02-12"
}
}

Fällt Ihnen etwas auf? Das Event enthält borrowedUntil (das Rückgabedatum), aber kein borrowedAt. Wer wissen will, wann das Buch tatsächlich ausgeliehen wurde, müsste auf den technischen Zeitstempel des Events zurückgreifen.

Aber hier liegt das Problem: Was, wenn der Leser das Buch bereits um 14:00 Uhr ausgeliehen hat, das System das Event aber erst um 14:02 Uhr geschrieben hat? Oder wenn der Bibliothekar die gestrigen Ausleihen erst heute Morgen eingetragen hat? Der technische Zeitstempel sagt uns, wann das Event gespeichert wurde, und nicht, wann die Ausleihe tatsächlich stattgefunden hat.

Warum technische Zeitstempel keine Geschäfts-Zeitstempel sind

Es gibt mehrere Gründe, warum der technische Zeitstempel für Geschäftslogik problematisch ist. Ein technischer Zeitstempel beschreibt, wann das System etwas getan hat. Ein Geschäfts-Zeitstempel beschreibt, wann etwas in der realen Welt passiert ist. Das sind zwei grundlegend verschiedene Konzepte und sie zu vermischen, kann zu subtilen Fehlern führen.

Das time-Feld eines Events beantwortet die Frage:

„Wann wurde dieses Event aufgezeichnet?“

Die fachliche Anforderung lautet aber oft:

„Wann ist das wirklich passiert?“

Das ist nicht dieselbe Frage. Und wichtig: Es geht hier nicht um Präzision oder Latenz, es geht vielmehr um Semantik.

Hinzu kommt: Ob ein Zeitstempelfeld überhaupt existiert, hängt vom Event-Format ab. CloudEvents enthält ein time-Feld, andere Formate aber möglicherweise nicht. Wer Events jemals in ein anderes Format konvertieren muss (etwa für Archivierung, Export oder Integration in andere Systeme), riskiert, dass der technische Zeitstempel verloren geht. Wenn Geschäftslogik von einem Feld abhängt, das bei einer Migration verschwinden könnte, baut man auf instabilem Grund.

Und das vielleicht stärkste Argument: Events werden häufig erst nach dem eigentlichen Ereignis aufgezeichnet. Ein paar Beispiele:

• Ein Bibliothekar stellt fest, dass jemand die gestrige Ausleihe mit dem falschen Datum eingetragen hat. Das Korrektur-Event schreibt er heute, obwohl es sich aber auf etwas bezieht, das gestern passiert ist.
• Eine mobile Bibliotheks-App erfasst eine Ausleihe, während das Gerät offline ist. Wenn es sich Stunden später synchronisiert, wird das Event erst dann persistiert, aber die eigentliche Ausleihe fand viel früher statt.
• Die Datenmigration aus einem Legacy-System importiert Jahre historischer Events. Die technischen Zeitstempel würden alle das heutige Datum zeigen und historische Analysen wertlos machen.
• Wenn das Zielsystem vorübergehend nicht erreichbar war, werden Events möglicherweise zwischengespeichert und später geschrieben. Der technische Zeitstempel zeigt den Schreibzeitpunkt, nicht das ursprüngliche Ereignis.

In all diesen Fällen liefert der technische Zeitstempel falsche Antworten für die Geschäftslogik.

Die Lösung: Zeit explizit machen

Das heißt: Wenn Zeit für das Geschäft relevant ist, gehört sie in die Event-Daten. Hier die verbesserte Version des Ausleihe-Events:

{
"source": "https://library.thenativeweb.io",
"subject": "/books/42",
"type": "io.thenativeweb.library.book-borrowed",
"data": {
"borrowedBy": "/readers/23",
"borrowedAt": "2026-01-12T14:00:00.000Z",
"borrowedUntil": "2026-02-12"
}
}

Jetzt ist die Semantik klar:

• borrowedAt: Wann das Buch tatsächlich ausgeliehen wurde (Geschäftszeit)
• borrowedUntil: Wann das Buch zurückgegeben werden muss (Geschäftszeit (das war schon korrekt))
• Event-Zeitstempel: Wann das System dieses Event aufgezeichnet hat (technische Zeit)

Interessant ist, dass borrowedUntil bereits ein Geschäftszeit-Feld war. Es fehlte nur das Gegenstück borrowedAt. Diese Inkonsistenz ist typisch: Entwickler denken oft daran, zukünftige Zeitpunkte aufzunehmen (Fristen, Fälligkeiten, Ablaufdaten …), vergessen aber gerne die vergangenen Zeitpunkte, also wann etwas tatsächlich geschehen ist.

Weitere Beispiele

Das Muster lässt sich auf andere Events übertragen:

• book-borrowed mit borrowedAt: Wann das Buch ausgeliehen wurde
• book-returned mit returnedAt: Wann das Buch zurückgegeben wurde
• reader-registered mit registeredAt: Wann sich der Leser angemeldet hat
• late-fee-charged mit chargedFor: Welchen Zeitraum die Gebühr abdeckt

Jedes dieser Felder beschreibt, wann etwas in der realen Welt passiert ist, unabhängig davon, wann das System es aufgezeichnet hat.

Wann der technische Zeitstempel akzeptabel ist

Heißt das, man sollte den technischen Zeitstempel komplett ignorieren? Nein. Es gibt legitime Verwendungszwecke: Debugging, um die Reihenfolge der Event-Persistierung nachzuvollziehen. Monitoring, um Systemlatenz und Durchsatz zu messen. Audit-Trails, um zu dokumentieren, wann Datensätze ins System gelangt sind.

Aber das sind alles technische Belange, keine fachlichen.

Und was ist mit dem technischen Zeitstempel als Fallback, wenn man vergessen hat, ein Geschäftszeit-Feld hinzuzufügen? Das ist ein Workaround, keine Lösung. Wer sich in dieser Situation wiederfindet, sollte erwägen, eine neue Version des Event-Typs einzuführen, die das explizite Zeitfeld enthält. Ja, dann muss man beide Versionen verarbeiten können, aber man gewinnt Klarheit und Korrektheit für die Zukunft.

Man sollte auch nicht versuchen, das Ganze mit

„die Latenz ist klein genug"

oder

„wir brauchen keine hohe Präzision"

zu beschönigen. Diese Argumente verfehlen den Punkt. Es geht nicht um Latenz oder Präzision, sondern es geht um semantische Klarheit. Ein technischer Zeitstempel und ein Geschäfts-Zeitstempel beantworten unterschiedliche Fragen, unabhängig davon, wie nah ihre Werte beieinander liegen mögen.

Fazit

Zeit wirkt einfach, bis man genauer hinschaut. Bei der Arbeit mit Events ist die Unterscheidung zwischen „wann etwas passiert ist" und „wann das System es aufgezeichnet hat" fundamental. Wer diese Grenze verwischt, riskiert subtile Bugs, fehlerhafte Reports und Systeme, die die Realität nicht korrekt abbilden.

Die Lösung ist einfach: Wenn Zeit für das Geschäft relevant ist, gehört sie explizit in die Event-Daten. Das zukünftige Ich (und alle, die diese Events später analysieren müssen) werden es danken. (who)