Transactional Outbox
Transactional Outbox speichert eine fachliche Änderung und ihre Versandabsicht in derselben lokalen Transaktion. Ein Relay veröffentlicht offene Einträge anschließend.
- Outbox-EintragVersandabsicht in der Datenbank.
- RelayVeröffentlicht offene Einträge später.
- Erneuter VersuchEintrag bleibt bis zur Übergabe offen.
Einordnung
Warum das wichtig ist
Wird erst gespeichert und dann separat gesendet, kann ein Ausfall dazwischen die Nachricht verlieren. Die Outbox speichert Absicht und Änderung zusammen. Die Verteilung der Nachrichten ist ein eigener Baustein.
Dieser Baustein erklärt atomare Speicherung vor einer Veröffentlichung. Für die Verteilung veröffentlichter Nachrichten siehe Queues, Pub/Sub & Streams.
Auf einen Blick · Daten und Ereignis in einer Transaktion
Vom Commit zur späteren Veröffentlichung
Variante mit dauerhaftem Nachrichtenkanal: Bestellung bestätigt B-1042 und speichert zugleich BestellungBestaetigt in ihrer Outbox. Der Nachrichtenkanal ist kurzzeitig nicht erreichbar.
So liest du das Bild
- Outbox-Eintrag Die Nachricht „B-1042 + Outbox O-8“ in einer lokalen Transaktion.
- Relay Die Spur Relay: „offene Outbox lesen“ und „O-8 veröffentlichen“.
- Erneuter Versuch „O-8 erneut veröffentlichen“ nach dem Ausfall; erst danach „als versendet markieren“.
Schritt 1 von 6 · Bestellung → Datenbank
B-1042 + Outbox O-8
eine lokale Transaktion
Nutzen & Grenzen
Hilft, wenn
- Eine lokale Transaktion speichert die fachliche Änderung samt Nachrichtenauftrag, sodass der Versandvorsatz dauerhaft bleibt.
- Getrennte Commit-Grenzen von Datenbank und Nachrichtenbroker machen ein Relay mit offenen Einträgen zur dauerhaften Veröffentlichungsbrücke.
- Beobachtbarer Fortschritt und permanente Fehlerzustände machen wiederholbare Zustellung nach einem Absturz betreibbar.
Grenzen
- Das Relay liefert mindestens einmal; Empfänger müssen Duplikate vertragen, etwa über Idempotenz.
- Der Versand erfolgt verzögert, und die Outbox-Tabelle muss aufgeräumt und auf Rückstau überwacht werden.
- Die Outbox sichert nur den lokalen Versandvorsatz; Verteilung und Aufbewahrung regelt Pub/Sub und Streams.
In der Praxis
- Schreibe fachliche Änderung und Outbox-Eintrag in derselben lokalen Transaktion. Das Relay liest offene Einträge, sendet sie und markiert Fortschritt erst nach erfolgreicher Veröffentlichung.
- Begrenze Relay-Wiederholungen und speichere Versandstatus sowie Fehlerursache. Ein permanenter Fehler braucht Alarm, Prüfung und eine kontrollierte Wiederfreigabe statt endloser Versuche.
- Empfänger müssen erneute Zustellung wiedererkennen, weil ein Relay nach dem Senden abstürzen kann. Dafür ist Idempotenz zuständig; lokale Kopplung erklärt Transaktionsgrenzen.
Ausführliche Erklärung lesen
Der Ablauf besteht aus zwei Phasen: Zuerst bestätigt die lokale Datenbanktransaktion die Geschäftsänderung zusammen mit dem Veröffentlichungseintrag. Anschließend liest ein eigenständiges Relay offene Einträge aus, veröffentlicht die Nachrichten und vermerkt seinen Fortschritt. Ein vorübergehend unerreichbarer Broker lässt die bereits gespeicherten Versandaufträge bestehen.
Ein Relay kann nach Veröffentlichung vor dem Fortschrittsvermerk ausfallen und denselben Eintrag erneut senden. Empfänger müssen daher Wiederholungen behandeln. Dauerhaft fehlerhafte Einträge brauchen einen sichtbaren Fehlerzustand, Alarmierung und einen kontrollierten Reparaturweg.
Transaktionsgrenzen sichern Änderung und Versandauftrag gemeinsam lokal; Zustellgarantien beschreiben, was nach Übergabe an den Transport noch offenbleibt.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Was bleibt nach dem fehlgeschlagenen ersten Versandversuch bestehen?
Lösung mit Begründung ansehen
Die bestätigte Bestellung und der offene Outbox-Eintrag O-8; das Relay kann später erneut senden.
AnwendenAuf eine neue Lage übertragen
Der Nachrichtenkanal ist für Stunden nicht erreichbar. Was passiert mit B-1042?
Lösung mit Begründung ansehen
Die Bestellung bleibt bestätigt, und O-8 bleibt offen. Sobald der Kanal erreichbar ist, kann das Relay veröffentlichen.
BewertenEine Alternative abwägen
Soll Bestellung direkt nach dem Commit selbst veröffentlichen, ohne Outbox? Wie wägst du ab?
Lösung mit Begründung ansehen
Das spart Tabelle und Relay. Ein Ausfall zwischen Commit und Veröffentlichung verliert aber die Nachricht. Die Outbox kostet mehr Bausteine, erhält dafür die Absicht.
Vertiefen
Diese optionalen Vertiefungen ergänzen das Lernziel dieser Seite.
Change Data Capture und Polling
Das Relay kann Outbox-Einträge regelmäßig abfragen (Polling) oder ihre Änderungen über Change Data Capture aus dem Transaktionslog übernehmen. Beide Varianten knüpfen an die gemeinsam gespeicherte Geschäftsänderung und den Outbox-Eintrag an.
Im Shop veröffentlicht das Relay so die gespeicherte Nachricht zur Bestellung. Auch bei Change Data Capture muss der Empfänger wiederholte Zustellungen behandeln; die gemeinsame lokale Transaktion und Idempotenz behalten ihre Aufgaben.
Weiterführende Bausteine
Quellen
- microservices.io · Transactional Outbox (öffnet in neuem Tab)Verbindet Datenänderung und Ereignisveröffentlichung über eine lokale Transaktion.
- Debezium · Outbox Event Router (öffnet in neuem Tab)Zeigt Change Data Capture für die verlässliche Veröffentlichung von Outbox-Ereignissen.
- AWS · Transactional Outbox (öffnet in neuem Tab)Erklärt das Dual-Write-Problem, Reihenfolge und Duplikatbehandlung.