The Dual Write Problem
A service often must update its database and publish an event, for example save an order and notify a message broker. Doing these as two separate operations risks a dual write failure, where the database commits but the publish fails, or vice versa, leaving the system inconsistent.
The Outbox Idea
The fix is to write the event into an outbox table in the same database transaction as the business data. Because both go through one atomic commit, either both persist or neither does. The event is now safely recorded alongside the state change.
The Relay
A separate relay process reads new rows from the outbox and publishes them to the broker, marking each as sent. This relay can poll the table or tail the database change log with change data capture. If a publish fails the relay simply retries, so delivery is at least once.
Idempotent Consumers
Because events may be delivered more than once, consumers must be idempotent, deduplicating by an event id so a repeat does no harm.
Key idea
The outbox pattern writes events into the same transaction as the data, then a relay publishes them with at least once delivery, eliminating the dual write problem as long as consumers stay idempotent.