Du musst die Datenbank aktualisieren und ein Event publishen. Wie verhinderst du, dass beides auseinanderläuft?

Nimm das Transactional-Outbox-Pattern: schreib das Event in derselben Transaktion wie die Statusänderung in eine Outbox-Tabelle, und lass dann einen separaten Relay pollen oder das Log mitlesen, publishen und als gesendet markieren. So gibt es einen Commit, du kannst also nie eine Zeile ohne Event oder ein Event ohne Zeile haben. Der Relay liefert At-least-once, Consumer müssen also weiterhin idempotent sein.

Die Falle ist, dass ein Datenbank-Commit und ein Broker-Publish zwei getrennte Systeme sind, jede Reihenfolge, die du wählst, hat also einen Fehlermodus. Publishst du zuerst, kann die Transaktion zurückrollen, und Consumer handeln auf etwas, das nie passiert ist. Committest du zuerst, kann der Prozess vor dem Publish sterben, das Event ist verloren und nichts wiederholt es. Das Outbox-Pattern schließt die Lücke: die Event-Zeile wird innerhalb derselben Transaktion wie die fachliche Änderung in eine Outbox-Tabelle eingefügt, entweder landen also beide oder keins. Danach liest ein Relay ungesendete Zeilen der Reihe nach, publisht sie und markiert sie als gesendet, und wenn er mitten im Publish abstürzt, publisht er einfach nochmal, weshalb Consumer idempotent sein müssen. Bin ich auf Postgres und will weniger Polling, nehme ich Change Data Capture vom Write-Ahead-Log mit etwas wie Debezium, dieselbe Garantie mit weniger selbstgebautem Code. Die operativen Details, die man einplanen sollte, sind das Aufräumen der Outbox und das Monitoring der Relay-Verzögerung, denn eine Outbox, die nicht mehr abfließt, sieht aus Sicht der Anwendung komplett gesund aus.