Ereignisse in Integrationen richtig ordnen: So verhindern Sie, dass alte Updates neue Daten überschreiben

Eine Integration erhält zuerst eine Adressänderung und danach ein Ereignis, laut dem der Kunde noch die alte Adresse hat. Werden beide Nachrichten in der Reihenfolge ihres Eingangs verarbeitet, ist der Datensatz anschließend veraltet. Das Problem ist nicht, dass das zweite Ereignis falsch wäre: Es kann gültig sein und lediglich früher stattgefunden haben.

Um Ereignisse in falscher Reihenfolge zu verarbeiten, muss man unterscheiden, wann eine Änderung stattgefunden hat und wann sie empfangen wurde. Außerdem muss klar sein, welche Informationsquelle darüber entscheidet, welcher Wert Vorrang hat. Eine allgemeingültige Regel auf Grundlage des Datums gibt es nicht. Die passende Entscheidung hängt von der Art des Ereignisses, der Datenerzeugung und der Zuständigkeit des jeweiligen Systems ab.

Warum Ereignisse in falscher Reihenfolge eintreffen

Eine Warteschlange, ein Webhook oder ein Integrationsprozess kann die Übermittlung eines Ereignisses verzögern. Nachrichten können erneut zugestellt, parallel verarbeitet oder über unterschiedlich schnelle Wege geleitet werden. Deshalb treffen zwei Ereignisse zu derselben Entität unter Umständen in einer anderen Reihenfolge ein, als sie erstellt wurden. Auch Duplikate sind möglich, wenn ein Absender nach einer ausbleibenden Bestätigung einen erneuten Zustellversuch unternimmt.

Die Reihenfolge kann innerhalb eines bestimmten Datenstroms erhalten bleiben, zwischen verschiedenen Datenströmen jedoch nicht. Änderungen an einem Konto könnten beispielsweise auf mehrere Partitionen verteilt werden, während Änderungen seiner Bestellungen unabhängig davon verarbeitet werden. Gehen Sie nicht davon aus, dass eine Warteschlange oder API eine globale Reihenfolge garantiert, sofern diese Eigenschaft nicht dokumentiert ist und auf dem tatsächlichen Übertragungsweg eingehalten wird.

Welche Folgen das hat, hängt vom Inhalt ab:

• Ein Ereignis mit vollständigem Zustand beschreibt, wie ein Datensatz zu einem bestimmten Zeitpunkt aussieht. Wird ein älterer Zustand später angewendet, kann er neuere Feldwerte überschreiben.
• Ein Delta-Ereignis beschreibt eine Änderung, etwa das Hinzufügen eines Tags oder das Erhöhen eines Zählers. Es allein wegen seines Alters zu verwerfen, könnte eine gültige Änderung verlieren, die noch nicht angewendet wurde.

Bevor Sie eine Regel festlegen, bestimmen Sie, ob Ihre Nachrichten vollständige Zustände, Teiländerungen oder eine Mischung aus beidem enthalten. Die richtige Strategie für eine Profiländerung eignet sich nicht unbedingt für einen Finanzvorgang oder einen Bestellstatuswechsel.

Eingangszeit, Ereigniszeit und fachliche Reihenfolge

Die Eingangszeit gibt an, wann das empfangende System die Nachricht registriert hat. Sie hilft dabei, Verzögerungen zu messen und die in diesem System eingegangenen Nachrichten zu ordnen. Sie belegt jedoch nicht, wann die ursprüngliche Änderung stattgefunden hat.

Die Ereigniszeit soll angeben, wann die Änderung erfolgt oder erfasst wurde. Sie kann für die Analyse hilfreich sein, hängt aber von der Systemuhr, deren Genauigkeit und den Konventionen des Absenders ab. Die Uhren zweier Systeme können voneinander abweichen. Auch ein während der Wiederaufnahme eines Prozesses erzeugtes Ereignis muss die fachliche Reihenfolge nicht exakt abbilden. Ein späterer Zeitstempel beweist für sich allein nicht, dass ein Ereignis Vorrang hat.

Die fachliche Reihenfolge bildet die Abfolge ab, die für eine Entität tatsächlich relevant ist: Beispielsweise folgt Version 12 eines Datensatzes auf Version 11 oder ein Vorgang wird nach einem anderen bestätigt. Liefert das Quellsystem eine monotone Version oder eine zuverlässige, derselben Entität zugeordnete Sequenznummer, ist das meist ein belastbareres Signal als die Uhrzeit. Prüfen Sie jedoch deren Geltungsbereich: Eine Nummer kann zurückgesetzt werden, nur für einen einzelnen Prozess gelten oder Änderungen verschiedener Entitäten nicht miteinander vergleichen.

Speichern Sie diese Werte getrennt. Verwenden Sie nicht ein einziges Feld namens „Datum“, um Vorrang zu bestimmen, Verzögerungen zu messen und Audit-Daten aufzubewahren. Für jeden Zweck braucht es eine eindeutige Interpretation.

Veraltete Updates erkennen, ohne gültige Änderungen zu verlieren

Ein Update ist nur gemessen an einer festgelegten Regel und dem aktuellen, dem Empfänger bekannten Zustand veraltet. Speichert das System beispielsweise Version 18 eines Kundendatensatzes und erhält einen vollständigen Zustand für Version 16, kann es diesen als älter ablehnen. Ein gültiges Delta sollte dagegen nicht automatisch verworfen werden, nur weil sein Zeitstempel früher liegt: Es könnte einen Wert ergänzen, der im späteren Ereignis gar nicht enthalten ist.

Prüfen Sie bei jeder Nachricht:

• Identität und Geltungsbereich: Auf welche Entität, welches Feld oder Aggregat bezieht sie sich? Zwei Änderungen können unabhängig voneinander sein und müssen nicht gegeneinander abgewogen werden.
• Typ und Version: Enthält die Nachricht einen vollständigen Zustand oder ein Delta, und lässt sich ihre Sequenz mit der bereits angewendeten vergleichen?
• Vorbedingungen: Ist der Übergang vom aktuellen Zustand aus zulässig? Eine Änderung auf „versandt“ sollte eine bereits „zugestellte“ Bestellung nicht ohne Erklärung zurücksetzen.
• Zuständigkeit: Welches System darf den Wert dieses Feldes festlegen? Eine Profiländerung und eine Korrektur aus dem führenden System haben nicht zwangsläufig dasselbe Gewicht.

Vergleich und Schreibvorgang müssen zusammenpassen. Lesen zwei Verbraucher Version 16 und versuchen beide, Änderungen zu speichern, kann eine vor dem Schreiben durchgeführte Prüfung bereits überholt sein. Verwenden Sie ein an die gelesene Version gebundenes bedingtes Update oder ein entsprechendes Verfahren im Speicher. So kann der Verbraucher erkennen, ob sich der Datensatz vor der Bestätigung seiner Änderung verändert hat.

Kriterien zur Konfliktlösung

Bevorzugen Sie das zuverlässigste tatsächlich vorhandene Signal. Erfinden Sie keine Rangfolge auf Grundlage von Feldern, die keine Reihenfolge garantieren. Die folgenden Kriterien lassen sich kombinieren, sofern ihre Bedeutung dokumentiert ist:

1. Version oder Sequenz pro Entität: Akzeptieren Sie einen vollständigen Zustand, wenn die Version steigt; ignorieren Sie eine bereits angewendete oder ältere Version. Legen Sie fest, wie Sie mit Sprüngen, Zurücksetzungen und fehlenden Versionen umgehen.
2. Zustand und zulässiger Übergang: Prüfen Sie die Änderung anhand eines Zustandsautomaten oder fachlicher Regeln. Ein ungültiger Übergang sollte eine Prüfung auslösen, statt stillschweigend als Update übernommen zu werden.
3. Zuständigkeit pro Feld: Ordnen Sie jedes Datum einem verantwortlichen System zu. Bearbeiten zwei Quellen dasselbe Feld berechtigterweise, braucht es eine ausdrückliche Regel, etwa eine Prüfung oder eine vereinbarte Priorität – keine improvisierte Regel nach dem Prinzip „zuletzt empfangene Nachricht gewinnt“.
4. Inhaltsvergleich: Wenden Sie idempotente Deltas an, sofern möglich, und ersetzen Sie nicht einen ganzen Datensatz durch eine Teilnachricht. Lässt sich aus dem Ereignis nicht erkennen, was sich geändert hat, fragen Sie vor dem Überschreiben die maßgebliche Quelle ab.

„Der letzte Schreibvorgang gewinnt“ kann bei wenig kritischen Feldern vertretbar sein, wenn Uhren und Vorgehensweise ausreichend kontrolliert sind. Neutral ist diese Regel nicht: Sie kann gültige Änderungen löschen und Konflikte verbergen. Bei wichtigen Entscheidungen sollten Sie beide Versionen erhalten oder die automatische Auflösung blockieren.

Was tun, wenn keine verlässliche Sequenz verfügbar ist?

Stellt der Absender keine vergleichbare Version bereit, sollten Sie keine exakte Reihenfolge aus der Eingangszeit ableiten. Wählen Sie eine Reaktion, die zu den Folgen einer möglichen Fehlentscheidung passt:

• Den aktuellen Zustand beim Quellsystem abfragen, bevor Sie aktualisieren, sofern eine verlässliche Lese-API verfügbar ist. Das verringert die Abhängigkeit von einer verspäteten Nachricht. Berücksichtigen Sie jedoch, dass auch zwischen Lesen und Schreiben eine spätere Änderung eintreten kann.
• Nur unabhängige Felder anwenden, wenn das Ereignis klar erkennen lässt, was geändert wurde. Behalten Sie die übrigen Werte bei und vermeiden Sie, den gesamten Datensatz zu ersetzen.
• Den Konflikt zur Abstimmung zurückhalten, wenn Kontext fehlt oder der Wert wichtig ist. Speichern Sie die Nachricht, die Entität und den Entscheidungsgrund, damit der Fall geprüft werden kann.
• Eine Quellenpriorität festlegen, wenn fachlich bestimmt wurde, welches System für ein Datum maßgeblich ist. Teilen Sie diese Regel den Teams mit und überprüfen Sie Ausnahmen.

Eine Prüfwarteschlange oder eine spätere Abfrage darf nicht zu einem unsichtbaren Wartestatus werden. Legen Sie fest, wer die Fälle bearbeitet, wie sie erneut angestoßen werden und woran die Lösung erkennbar ist. Ist keine automatische Entscheidung möglich, ist es sicherer, die Unsicherheit sichtbar zu machen, als einen fraglichen Wert als aktuell darzustellen.

Tests und Protokolle zur Überprüfung des Verhaltens

Testen Sie den Integrationsvertrag und nicht nur den idealen Ablauf. Senden Sie für dieselbe Entität zwei Änderungen in umgekehrter Reihenfolge, wiederholen Sie ein bereits verarbeitetes Ereignis, verzögern Sie eine Nachricht während eines erneuten Zustellversuchs und lösen Sie nahezu gleichzeitige Schreibvorgänge aus. Berücksichtigen Sie auch gleiche, fehlende oder unerwartete Versionen, sofern solche Fälle in der Quelle auftreten können.

Prüfen Sie nicht nur den Endwert, sondern auch die getroffene Entscheidung: angenommen, als Duplikat oder veraltet ignoriert, zusammengeführt, zurückgehalten oder wegen eines ungültigen Übergangs abgelehnt. Vergewissern Sie sich, dass wiederholte Nachrichten keine zusätzlichen Auswirkungen haben und gültige Ereignisse nicht aufgrund einer reinen Datumsregel verloren gehen.

Protokollieren Sie die Ereignis-ID, die Entität, die Quelle, die verfügbare Version oder Sequenz, Ereignis- und Eingangszeit, die vorherige und die nachfolgende Version sowie den Entscheidungsgrund. Vermeiden Sie unnötige personenbezogene Daten in Protokollen. Beobachten Sie das Alter der Nachrichten und die Zahl der Konflikte: Ein Anstieg kann auf Verzögerungen, erneute Zustellversuche oder Änderungen beim Absender hindeuten, nicht zwingend auf einen Fehler des empfangenden Systems.

Entscheidungscheckliste vor dem Start der Integration

• Stellt jede Nachricht einen vollständigen Zustand, ein Delta oder beide Typen dar?
• Welches Feld bestimmt den Vorrang, und wer gewährleistet seinen Geltungsbereich und seine Kontinuität?
• Welches System ist für welche Daten maßgeblich, und welche Änderungen darf jede Quelle liefern?
• Wie werden Duplikate und gleichzeitige Schreibvorgänge verhindert, die eine Prüfung ungültig machen könnten?
• Was geschieht bei fehlenden Sequenzen, ungültigen Übergängen und unklaren Konflikten?
• Wer prüft zurückgehaltene Fälle, und wie wird die Zeit bis zu ihrer Klärung gemessen?

Entscheidend ist, das zuverlässigste verfügbare Reihenfolgensignal zu nutzen, jedes Ereignis auf die Daten zu begrenzen, die es tatsächlich ändert, und Unsicherheit ausdrücklich zu behandeln. So lässt sich eine verspätete Nachricht erkennen, ohne gültige Änderungen blind zu verwerfen oder zuzulassen, dass ein altes Update den aktuellen Stand überschreibt.