Outbox Pattern
Outbox Pattern stores an integration event alongside business state in the same local transaction, then releases that event asynchronously through a relay process. It makes reliable publication a two-step process: record first, deliver second.
βΆArchitecture Diagram
π Data FlowDashed line animations indicate the flow direction of data or requests
The classic dual-write problem happens when a database update succeeds but event publication fails, or vice versa. Without a pattern like outbox, downstream systems can miss important changes because state and messaging are not committed together.
Distributed transactions proved too costly or too constrained for many cloud-native and microservice systems. At the same time, event-driven collaboration became common. Outbox Pattern spread because teams needed a practical way to reduce lost events without restoring heavyweight global transactions.
The application updates business data and writes an outbox row in one transaction. A relay or CDC process later reads the outbox and publishes to a broker, managing retries or sent markers along the way. Because relays can repeat work, consumers usually need to tolerate duplicates.
Event Sourcing treats events as the primary source of truth. Outbox Pattern keeps current-state storage as the source of truth and focuses only on reliable outward publication. Saga coordinates multi-step flows across services; Outbox solves one service's local state-plus-event consistency problem.
It is common whenever one service changes local state and must notify other systems reliably afterward, such as order creation, payment completion, or user-status changes. The pattern only really works when cleanup, relay lag, and duplicate handling are designed alongside it.