Updates inventory record
Backend & Runtime / Knowledge library
Transactional Outbox Pattern
Writes domain changes and pending messages in one local transaction
Why learn Transactional Outbox Pattern?
It reliably connects database commits to asynchronous publication
The problem it solves
It prevents committed state from losing its corresponding event
Where it came from
Transactional Outbox Pattern is a software design pattern that writes domain changes and pending messages in one local transaction. Its guarantees and tradeoffs depend on the concrete implementation and operating context.
Build your understanding
Work through these exercises in order. Try the task before opening a reference.
- Define Transactional Outbox Pattern and distinguish it from a neighboring concept.
- Choose a realistic task where Transactional Outbox Pattern is appropriate.
- Identify a failure mode caused by misusing Transactional Outbox Pattern.
- Interpret a small design or result involving Transactional Outbox Pattern.
- Explain one tradeoff or limitation of Transactional Outbox Pattern.
Documentation and sources
- Patterns of Enterprise Application Architecture (martinfowler.com)
Connect the ideas
Explore next
Real World Example
Synchronizing Inventory and Shipping Notifications
E-commerce platforms managing high-volume warehouse inventory updates.
The business problem
When an inventory update succeeds in the database but the subsequent message to the shipping service fails due to network instability, the system enters an inconsistent state where inventory is reduced but no shipment is triggered.
How this topic solves it
The Transactional Outbox pattern ensures atomicity by writing the domain state change and the corresponding integration event into the same database transaction, using a local 'Outbox' table as a persistent staging area for downstream delivery.
- Define an Outbox table in the primary database schema to store serialized event payloads.
- Wrap the business logic update and the insertion of the event into the Outbox table within a single ACID transaction.
- Implement a separate background process or polling mechanism to read pending events from the Outbox table.
- Publish the read events to the message broker and mark them as processed upon successful acknowledgment.
- Delete or archive the processed events from the Outbox table to maintain performance.
Shows the flow from business logic to the outbox and eventual message dispatch.
Stores pending event
Background poller
External queue
- Business Logic → Atomic Transaction → Outbox Table
- Outbox Table → Read Pending → Message Relay
- Message Relay → Publish Event → Message Broker
Expected business outcome
Guaranteed at-least-once delivery of integration events, ensuring that downstream services eventually synchronize with the primary domain state despite transient network failures.
Limitations and checks
The pattern introduces a risk of duplicate message delivery if the background publisher crashes after sending the message but before marking it as processed in the Outbox table; downstream consumers must be idempotent.