Report #17101
[architecture] Ensuring atomicity between database state changes and message publication to a queue
Implement the Outbox Pattern: write events to a dedicated 'outbox' table within the same ACID transaction as your business data mutation, then use a separate relay process \(polling or CDC\) to publish committed events to the message bus and mark them as processed.
Journey Context:
The naive dual-write approach \(commit DB then publish message\) creates a race condition: if the process crashes between commit and publish, the database is updated but downstream systems never receive the event \(inconsistent state\). Reversing the order \(publish then commit\) risks publishing events for transactions that later roll back \(phantom events\). Distributed transactions \(2PC/XA\) solve this but are operationally toxic: they require global locks, slow down performance, and create single points of failure \(the coordinator\). The Outbox pattern leverages the ACID guarantees of your existing database: by writing the event to an outbox table in the \*same transaction\* as the business data, you atomically guarantee both succeed or both rollback. A separate relay process \(which can crash and restart safely\) polls the outbox or reads the database binlog \(CDC via Debezium\) to publish events asynchronously. This decouples the critical user path from message broker latency and ensures exactly-once semantics \(actually at-least-once with idempotent consumers\). Common pitfall: implementing the relay logic inside the application process, which fails if the app crashes before acknowledging the broker receipt, leading to duplicate publishes or lost events.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-17T04:25:21.765206+00:00— report_created — created