Saga + Outbox: Durable Distributed Transactions (2026)

Q: What is the Saga + Outbox combination?

A pair of patterns deployed together where Saga orchestrates a multi-service workflow as local transactions with compensations, and Outbox guarantees that every state change is durably emitted to the broker as part of the same database transaction. Together they provide durable, restart-safe distributed transactions without distributed locks.

Q: Why is Saga insufficient on its own?

Saga assumes that when a service writes its local state and emits the next command, both happen reliably. Without Outbox, a crash between the database write and the broker publish leaves the saga stuck in a state where the database says step 2 done but the broker never received start step 3, and the saga halts.

Q: Why is Outbox insufficient on its own?

Outbox guarantees durable event emission but does not orchestrate multi-step workflows or compensations. With only Outbox, when step 4 of a workflow fails, there is no machinery to roll back steps 3, 2, and 1 — the application code has to implement that ad-hoc, which is exactly what Saga formalises.

Q: Where should the saga orchestrator live?

In its own dedicated service with its own saga table and its own outbox. Combining it with the originating service couples two different lifecycles. Combining all sagas into one orchestrator process produces a deployment and database hot-spot. One orchestrator per business capability is the typical decomposition.

Q: What is the latency cost of using Outbox?

With polling-based relays running at 100 to 500ms intervals, each saga step adds roughly 100 to 500ms of latency for the outbox-to-broker hop. With CDC-based relays such as Debezium, the additional latency is sub-100ms. For most workflows this is invisible to users.

Q: Can the same database hold both the saga table and the outbox table?

Yes, the orchestrator service owns one database that holds both. They must be in the same database so the state transition and the outbox insert are in the same atomic transaction. Splitting them across databases reintroduces the race condition Outbox is designed to prevent.

Q: How does this combination handle exactly-once delivery?

It does not. The underlying delivery is at-least-once. Exactly-once business semantics are achieved by consumers being idempotent — every handler uses a deduplication key, typically sagaId plus stepId, and a processed_messages table. At-least-once delivery plus idempotent consumers gives effectively-once business behaviour.

Q: What happens if a compensation step fails?

The orchestrator retries the compensation via outbox until it succeeds, with exponential backoff. If retries are exhausted, the saga is moved to a stuck state and a human is alerted. Compensations are themselves idempotent and outbox-backed, so they survive crashes the same way forward steps do.

Q: How do I detect a stuck saga?

Every state transition records step_started_at and step_timeout_seconds in the saga table. A background job runs every minute, scans for sagas where now() minus step_started_at exceeds step_timeout_seconds, and routes them to a stuck state with an alert. Without this detector, sagas accumulate silently in long-broken states.

Q: Should I use polling or CDC for the outbox relay?

Polling is simpler and adequate up to a few hundred outbox writes per second per service. CDC such as Debezium becomes worth its operational cost above that throughput, or when end-to-end latency budgets demand sub-100ms outbox-to-broker latency. Most teams start with polling and migrate to CDC when needed.