Transactional Outbox, Sagas, and Event Sourcing

The dual-write problem occurs when an application updates a database and publishes a message separately: one operation can succeed while the other fails. The transactional outbox writes the business change and an outbox record in the same database transaction; a relay later publishes the record. Consumers still need idempotency.

A saga coordinates a business workflow across services using local transactions and compensating actions. For example, a travel booking may reserve a flight, reserve a hotel, and then confirm both; if the hotel reservation fails, the system releases the flight reservation. Compensation is a new business action, not a magical rollback of history.

Event sourcing stores state changes as an event log and derives current state by replay or projection. It supports auditability and alternate projections but introduces schema evolution, replay cost, event correction, and operational complexity. It is not required merely because a system publishes events.

Transactional outbox flow
Key Takeaways
  • Use an outbox to avoid losing the link between a database commit and event publication.
  • Sagas need explicit compensation and reconciliation.
  • Event sourcing is a data-model choice with significant lifecycle costs.