The dual write problem
A service often needs to update its database and publish a message to a broker. Doing both as two separate calls creates the dual write problem: the database commit may succeed while the publish fails, or the reverse. Now your data and your events disagree.
How the outbox fixes it
The outbox pattern writes the event into an outbox table inside the very same local transaction that changes your business data. Because they share one transaction, they commit together atomically. A separate relay process then reads unsent rows from the outbox and publishes them to the broker, marking each as sent.
- One atomic write for data and event.
- A relay moves events to the broker after commit.
- Consumers must tolerate at least once delivery and dedupe by event id.
Reading the outbox
The relay can poll the table for new rows, or it can tail the database change log with change data capture so events flow without polling.
Because publishing happens after a durable commit, an event is never lost, though it may be delivered more than once.
Key idea
The outbox makes data changes and event publishing atomic by committing both in one transaction and relaying later.