Stop Writing Dual-Writes: Why Your "Update DB + Publish Event" Architecture Is Leaking State
Dual-writes are one of the most common distributed traps in modern backend development.
The code looks clean on a pull request:
Start database transaction.
Update the entity (e.g., orders.updateStatus('PAID')).
Commit transaction.
Send event: broker.publish('order.paid', event).
Here is the problem: Network partitions and process crashes do not respect your happy path.
If step 3 succeeds, but the process crashes or the broker times out before step 4 finishes, downstream services never know the order was paid.
If you flip the order and publish the event before committing the database transaction, downstream consumers process an event for a state change that could roll back on database failure.
Wrapping both in a generic try/catch block doesn't fix it. Distributed transactions across heterogeneous systems (ACID database + AMQP/Kafka/SQS) cannot be solved cleanly by application runtime retries without introducing duplicate events, zombie states, or race conditions.
The Architectural Fix: The Transactional Outbox Pattern
Instead of publishing directly to your broker from the application layer:
Write the event payload directly into an outbox table inside the exact same ACID database transaction as your entity update.
If the entity write rolls back, the outbox record rolls back. If it commits, the event is guaranteed to persist.
A separate worker or Change Data Capture (CDC) engine (such as Debezium reading the database Write-Ahead Log/WAL) tails the outbox table and pushes events downstream with guaranteed at-least-once delivery.
Downstream consumers maintain idempotency keys to handle the inevitable re-deliveries safely.
This decouples the durability of your event from the availability of your network.
Discussion Question
When building event-driven services, how does your current team tackle the dual-write dilemma—do you rely on the Outbox Pattern with CDC, two-phase commits, distributed Sagas, or do you accept eventual consistency edge cases until they break?
CTA
Share a snippet of your idempotency middleware or drop a link/repo to how your service handles reliable event publishing under network failure!
Dual-writes are one of the most common distributed traps in modern backend development.
The code looks clean on a pull request:
Start database transaction.
Update the entity (e.g., orders.updateStatus('PAID')).
Commit transaction.
Send event: broker.publish('order.paid', event).
Here is the problem: Network partitions and process crashes do not respect your happy path.
If step 3 succeeds, but the process crashes or the broker times out before step 4 finishes, downstream services never know the order was paid.
If you flip the order and publish the event before committing the database transaction, downstream consumers process an event for a state change that could roll back on database failure.
Wrapping both in a generic try/catch block doesn't fix it. Distributed transactions across heterogeneous systems (ACID database + AMQP/Kafka/SQS) cannot be solved cleanly by application runtime retries without introducing duplicate events, zombie states, or race conditions.
The Architectural Fix: The Transactional Outbox Pattern
Instead of publishing directly to your broker from the application layer:
Write the event payload directly into an outbox table inside the exact same ACID database transaction as your entity update.
If the entity write rolls back, the outbox record rolls back. If it commits, the event is guaranteed to persist.
A separate worker or Change Data Capture (CDC) engine (such as Debezium reading the database Write-Ahead Log/WAL) tails the outbox table and pushes events downstream with guaranteed at-least-once delivery.
Downstream consumers maintain idempotency keys to handle the inevitable re-deliveries safely.
This decouples the durability of your event from the availability of your network.
Discussion Question
When building event-driven services, how does your current team tackle the dual-write dilemma—do you rely on the Outbox Pattern with CDC, two-phase commits, distributed Sagas, or do you accept eventual consistency edge cases until they break?
CTA
Share a snippet of your idempotency middleware or drop a link/repo to how your service handles reliable event publishing under network failure!
Stop Writing Dual-Writes: Why Your "Update DB + Publish Event" Architecture Is Leaking State
Dual-writes are one of the most common distributed traps in modern backend development.
The code looks clean on a pull request:
Start database transaction.
Update the entity (e.g., orders.updateStatus('PAID')).
Commit transaction.
Send event: broker.publish('order.paid', event).
Here is the problem: Network partitions and process crashes do not respect your happy path.
If step 3 succeeds, but the process crashes or the broker times out before step 4 finishes, downstream services never know the order was paid.
If you flip the order and publish the event before committing the database transaction, downstream consumers process an event for a state change that could roll back on database failure.
Wrapping both in a generic try/catch block doesn't fix it. Distributed transactions across heterogeneous systems (ACID database + AMQP/Kafka/SQS) cannot be solved cleanly by application runtime retries without introducing duplicate events, zombie states, or race conditions.
The Architectural Fix: The Transactional Outbox Pattern
Instead of publishing directly to your broker from the application layer:
Write the event payload directly into an outbox table inside the exact same ACID database transaction as your entity update.
If the entity write rolls back, the outbox record rolls back. If it commits, the event is guaranteed to persist.
A separate worker or Change Data Capture (CDC) engine (such as Debezium reading the database Write-Ahead Log/WAL) tails the outbox table and pushes events downstream with guaranteed at-least-once delivery.
Downstream consumers maintain idempotency keys to handle the inevitable re-deliveries safely.
This decouples the durability of your event from the availability of your network.
Discussion Question
When building event-driven services, how does your current team tackle the dual-write dilemma—do you rely on the Outbox Pattern with CDC, two-phase commits, distributed Sagas, or do you accept eventual consistency edge cases until they break?
CTA
Share a snippet of your idempotency middleware or drop a link/repo to how your service handles reliable event publishing under network failure!
Arabic
French
Spanish
Portuguese
Deutsch
Turkish
Dutch
Italiano
Russian
Romaian
Portuguese (Brazil)
Greek