Transactional Outbox
Publish events reliably by committing business state and message intent in one local transaction.
2–5 minute refresher
Coordinator
1 · PREPARE↓2 · COMMIT / ABORT
Inventoryready ✓
Paymentready ✓
Ledgerready ✓
Commit the fact and the promise to publish together; deliver the promise asynchronously.
30second
refresher
refresher
A service writes its domain change and an outbox row in the same database transaction. A relay or change-data-capture pipeline later publishes the row to the broker and marks progress.
What problem does it solve?
Writing a database and broker separately creates a dual-write gap: either the state commits without its event or the event publishes without the state.
How it works
- Begin the local database transaction.
- Write the domain state and immutable outbox record.
- Commit them together.
- Relay unpublished records with stable event IDs.
- Publish at least once and let consumers deduplicate.
Decision guide
Key trade-offs
| Choice | What you gain | What it costs |
|---|---|---|
| Polling relay | Portable and simple | Polling latency and load |
| CDC relay | Low-latency ordered capture | Operational coupling to logs |
| Delete after send | Small table | Harder audit and replay |
What happens if?
Publish succeeds before acknowledgement
The broker accepts an event, but the relay crashes before recording progress. The event is published again after restart; without consumer idempotency the business effect repeats.
Where it appears
- Order services
- Payment workflows
- Cache invalidation
- Audit pipelines
Senior interview modeDoes an outbox provide exactly-once delivery?Show answer
No. It provides atomic state-plus-intent and normally at-least-once publication. Exactly-once business outcomes still require stable event identity, idempotent consumers, and careful handling of external effects.