Events zuverlässig veröffentlichen mit einer transaktionalen Outbox

Ziel

Garantieren, dass jede committete Zustandsänderung ihr Event genau dann erzeugt, wenn die Änderung committet wird, ohne eine verteilte Transaktion zwischen Datenbank und Message Broker.

Voraussetzungen

Ein Dienst, der seine Datenbank besitzt und Events an einen Broker veröffentlicht; Konsumentinnen, die Duplikate vertragen (Deduplizierung nach Message-ID). Die (zitierte) Muster-Seite auf microservices.io beschreibt das Problem: Ein Dienst muss atomar seine Datenbank aktualisieren und eine Nachricht senden, und Nachrichten für ein Aggregat müssen ihre Reihenfolge über Dienstinstanzen hinweg beibehalten.

Schritte

1. Eine Tabelle outbox anlegen: id (eindeutig, wird zur Message-ID), aggregate_type, aggregate_id, event_type, payload (JSON), created_at, und, nur für die Polling-Variante, published_at (nullable). Debeziums Standard-Spaltennamen sind id, aggregatetype, aggregateid, type und payload; andere Namen werden über dessen Optionen zugeordnet.
2. In der Anwendungstransaktion, die den Zustand ändert, eine Outbox-Zeile pro Event einfügen. Committen. Sonst geschieht nichts weiter im Request-Pfad.
3. Ein Relay wählen:
   • Polling Publisher: Ein Worker wählt unveröffentlichte Zeilen in id-Reihenfolge aus (FOR UPDATE SKIP LOCKED in PostgreSQL, um mehrere Worker zuzulassen), veröffentlicht jede an den Broker mit der Zeilen-ID als Message-ID und der Aggregat-ID als Partitionsschlüssel, und setzt dann published_at.
   • Log Tailing: Ein Change-Data-Capture-Connector liest das Datenbank-Log. Debeziums (zitierter) Outbox Event Router erfasst Inserts in die Outbox-Tabelle, leitet jede Zeile an ein aus dem Aggregattyp abgeleitetes Topic weiter und verwendet die Aggregat-ID als Message-Key. Seine Dokumentation hält fest, dass Updates an Outbox-Zeilen nicht erlaubt sind und Deletes herausgefiltert werden, weshalb die Tabelle bei dieser Variante nur Inserts kennt: Zeilen werden nachträglich gelöscht, nie markiert.
4. Akzeptieren, dass ein Absturz zwischen dem Veröffentlichen und dem Markieren (oder, beim Log Tailing, zwischen dem Veröffentlichen und dem Aufzeichnen der Position durch den Connector) ein Duplikat erzeugt; broker-seitige Producer-Idempotenz, sofern angeboten, deckt Retries innerhalb einer Producer-Sitzung ab, nicht ein neu gestartetes Relay. Konsumentinnen deduplizieren nach Message-ID.
5. Veröffentlichte Zeilen nach Zeitplan löschen oder archivieren; die Tabelle klein halten, damit die Poll-Abfrage günstig bleibt.
6. Das Alter der ältesten unveröffentlichten Zeile und deren Anzahl überwachen; alarmieren, wenn das Relay stockt.

Erwartetes Ergebnis

Kein Event ohne committete Änderung und keine Änderung ohne Event. Konsumentinnen sehen jedes Event mindestens einmal, in Reihenfolge pro Aggregat, sofern das Relay die Einfügereihenfolge bewahrt und der Broker die Reihenfolge pro Schlüssel bewahrt.

Grenzen und Prüfbasis

Polling fügt eine Latenz von einem Poll-Intervall hinzu; Log Tailing braucht CDC-Infrastruktur und Datenbankberechtigungen. Die Reihenfolge über verschiedene Aggregate hinweg ist nicht garantiert. Testen, indem das Relay mitten im Batch gekillt wird und indem die Anwendung zwischen dem geschäftlichen Schreibvorgang und dem Commit zum Absturz gebracht wird; die Outbox darf weder verwaiste noch fehlende Events zeigen.

Reihenfolge mit einem Polling-Relay

Mehrere Polling-Worker, die SKIP LOCKED verwenden, bewahren die Reihenfolge pro Aggregat nicht: Ein Worker kann eine spätere Zeile für ein Aggregat veröffentlichen, bevor ein anderer Worker eine frühere veröffentlicht, und eine Zeile mit niedrigerer id kann später sichtbar werden als eine Zeile mit höherer, weil Transaktionen nicht in ID-Reihenfolge committen. Hängen Konsumentinnen von der Reihenfolge pro Aggregat ab, einen einzelnen Publishing-Worker betreiben oder Worker anhand eines Hashs von aggregate_id partitionieren, sodass die Zeilen eines Aggregats stets vom selben Worker behandelt werden, und von der ältesten unveröffentlichten Zeile aus pollen statt von der zuletzt gesehenen ID. Das Log-Tailing-Relay vermeidet beide Probleme, weil es Commits in Commit-Reihenfolge liest.