FACHBEITRAG · IT-INFRASTRUKTUR

Transactional Outbox: Geschäftszustand, Ereignisreihenfolge und Wiederholung konsistent halten

25.10.2026 · Fachlich überarbeitete Fassung / Revised article

BestExperts – Automatisierung und Zusammenarbeit / automation and collaboration

Zwischen Datenbank-Commit und Nachrichtenversand liegt ein Ausfallfenster. In verteilten Geschäftsprozessen ist das keine seltene Sonderlage, sondern eine zu beherrschende Zustandskombination. Eine Outbox löst die atomare Erfassung der Versandabsicht. Sie garantiert allein weder eine einmalige Zustellung noch eine einmalige fachliche Wirkung beim Empfänger.

Die Transaktionsgrenze bewusst setzen

Geschäftsänderung und Outbox-Eintrag werden in derselben lokalen Datenbanktransaktion geschrieben. Ein separater Relay überträgt bestätigte Einträge zum Broker. Scheitert die Transaktion, darf kein zugehöriges Ereignis sichtbar werden. Nach erfolgreichem Commit muss die Versandabsicht auch nach einem Prozessneustart erhalten bleiben.

Der Relay kann nach der Broker-Bestätigung und vor seiner lokalen Fortschrittsmarkierung ausfallen. Beim Wiederanlauf sendet er erneut. Deshalb benötigen Ereignisse stabile Kennungen und Empfänger eine Duplikaterkennung, deren Zustandsänderung gemeinsam mit der Geschäftswirkung konsistent gespeichert wird.

Reihenfolge pro Geschäftsobjekt statt globale Reihenfolge

Ein Auftrag wechselt von „freigegeben“ auf „storniert“. Werden Ereignisse durch parallele Relay-Worker vertauscht, kann ein nachgelagerter Dienst einen veralteten Zustand wiederherstellen. Aggregatkennung und fortlaufende Version erlauben es, Duplikate, Lücken und veraltete Ereignisse voneinander zu unterscheiden. Eine einzelne globale Sequenz ist häufig unnötig und kann zum Skalierungsengpass werden.

Bei einer Lücke muss der Empfänger warten, gezielt nachladen oder einen definierten Snapshot-Abgleich auslösen. Einfach nur die höchste Version zu speichern reicht nicht, wenn übersprungene Ereignisse eigenständige Geschäftswirkungen tragen.

Rückstau als Kapazitätsproblem rechnen

Im vereinfachten Beispiel entstehen 500 Ereignisse pro Sekunde. Nach 20 Minuten Ausfall liegen 600.000 Einträge vor. Verarbeitet der Relay nach Wiederanlauf 800 pro Sekunde, bleiben unter unveränderter Ankunftsrate 300 pro Sekunde zum Abbau.

TAbbau = Rückstau / (Verarbeitung − Ankunft) = 600.000 / 300 s = 33 min 20 s

Die Rechnung gilt nur bei stabilen Raten und ausreichender Broker- und Empfängerkapazität. Gemessen werden zusätzlich Alter des ältesten ungesendeten Ereignisses und blockierte Aggregate. Eine kleine Warteschlange kann bereits geschäftskritisch sein, wenn ihr ältester Eintrag eine Frist überschreitet.

Fehlerinjektion gehört zur Freigabe

Getestet werden Absturz vor und nach Commit, doppelte Zustellung, vertauschte Reihenfolge sowie giftige Nachrichten. Aufbewahrung und Bereinigung dürfen die Nachweisführung nicht vorzeitig zerstören. Der Abnahmemaßstab ist die konsistente Geschäftswirkung nach Wiederanlauf.

Einfach erklärt: Nutzen in der Praxis

Ein Webshop speichert einen Auftrag, während der Nachrichtendienst ausfällt. Die Outbox hält fest, dass die Versandinformation noch übertragen werden muss. Nach dem Wiederanlauf wird sie nachgeliefert, ohne dass der Kunde versehentlich zwei Lieferungen erhält.

WordPress Cookie Plugin von Real Cookie Banner