Transactional Outbox
Transaktionale Outbox
Ein transaktionaler Ausgangspeicher speichert eine Datenänderung und einen Nachrichten-Eintrag in einer lokalen Datenbanktransaktion. Ein Relay sendet die gespeicherte Nachricht, nachdem die Transaktion abgeschlossen ist.
local transaction(business row + outbox row) -> relay/CDC -> broker -> idempotent consumerorders✓order_2048outbox✓evt_784local transaction(business row + outbox row) -> relay/CDC -> broker -> idempotent consumerJOBEin weiteres Beispiel
Der Checkout speichert die Bestellung `984` und das Outbox-Ereignis `OrderCreated:984` in einer Transaktion. Ein Relay veröffentlicht das Ereignis später. Wenn es nach dem Senden, aber vor dem Markieren der Zeile stoppt, kann es erneut senden. Der Verbraucher entfernt das Duplikat anhand der Ereignis-ID.
Hauptteile
- 01Änderung von Geschäftsdaten
- 02Outbox-Ereigniszeile
- 03Eine lokale Transaktion
- 04Relay- oder Änderungsstrom
- 05Broker-Veröffentlichung
- 06duplikatsicherer Verbraucher
Verwenden Sie es, wenn
Verwenden Sie es, wenn eine verpflichtende Datenbankänderung zuverlässig zu einer Nachricht oder einem Ereignis führen muss. Halten Sie das Outbox in derselben Transaktion und betreiben Sie das Relay als eigenen zuverlässigen Prozess.
Nutze es nicht, wenn
Nenne es nicht einmalige Lieferung oder eine Transaktion über Dienste hinweg. Plane für wiederholte Ereignisse, deren Reihenfolge, Übertragungsverzögerung, Bereinigung und sichere Handhabung von Duplikaten.
In Code verwendeter Name
local transaction(business row + outbox row) -> relay/CDC -> broker -> idempotent consumer Vor dem Ausliefern
Check contracts and invariants, authorization, and input limits. Test retries, one-time effects, timeouts, and partial failures. Verify data integrity, compatibility, monitoring, recovery, and rollback.
Outcome: Complete the task with Transaktionale Outbox (Transactional Outbox). User context: Der Checkout speichert die Bestellung `984` und das Outbox-Ereignis `OrderCreated:984` in einer Transaktion. Ein Relay veröffentlicht das Ereignis später. Wenn es nach dem Senden, aber vor dem Markieren der Zeile stoppt, kann es erneut senden. Der Verbraucher entfernt das Duplikat anhand der Ereignis-ID. Technical concept or control: Transaktionale Outbox (Transactional Outbox). Why it fits: Verwenden Sie es, wenn eine verpflichtende Datenbankänderung zuverlässig zu einer Nachricht oder einem Ereignis führen muss. Halten Sie das Outbox in derselben Transaktion und betreiben Sie das Relay als eigenen zuverlässigen Prozess. Do not use it when: Nenne es nicht einmalige Lieferung oder eine Transaktion über Dienste hinweg. Plane für wiederholte Ereignisse, deren Reihenfolge, Übertragungsverzögerung, Bereinigung und sichere Handhabung von Duplikaten. Engineering requirements: Define inputs, outputs, contracts, and rules that must always hold. Set authorization and input checks. Define failures, timeouts, retries, one-time effects, data moves, and compatibility limits. Operations: Add useful signals and logs that hide sensitive data. Set capacity limits and write an operator guide. Test recovery and rollback. Acceptance criteria: Contract and failure-path tests pass. Data and authorization rules still hold during retries and partial failures. Check performance limits, monitoring, recovery, and rollback. Evidence and limits (evidence boundary): Kein einziger offizieller Standard kontrolliert den gesamten Begriff. Seine Bedeutung kann sich zwischen Teams, Plattformen oder Frameworks ändern. Unknowns to confirm: Where the code runs, data stores, traffic shape, consistency needs, and the security boundary. Also confirm the compatibility period, service goals, and rollback limits.
Diese Anfrage prüfen
Review how Transaktionale Outbox (Transactional Outbox) is used now. Definition: Ein transaktionaler Ausgangspeicher speichert eine Datenänderung und einen Nachrichten-Eintrag in einer lokalen Datenbanktransaktion. Ein Relay sendet die gespeicherte Nachricht, nachdem die Transaktion abgeschlossen ist. Release checks: Check contracts and invariants, authorization, and input limits. Test retries, one-time effects, timeouts, and partial failures. Verify data integrity, compatibility, monitoring, recovery, and rollback. Before changing code, list the evidence, gaps, severity, and the smallest safe fix.