2PC Alternatives: Saga vs TCC vs Outbox vs Reservation (2026)

Q: Why does two-phase commit fail in microservices?

Two-phase commit fails in microservices for four reasons. First, it blocks: participants that vote yes in the prepare phase must hold their locks until the coordinator sends a global decision, and if the coordinator crashes the participant blocks indefinitely. Second, it requires the XA protocol on every participant, which is not supported by most NoSQL stores, REST APIs, third-party payment processors, or message brokers — common parts of any modern stack. Third, it holds locks across network latency including third-party API calls (200ms to 2s), which serialises the system on the latency of the slowest external dependency. Fourth, network partitions break its safety guarantees — participants on one side of a partition cannot make progress and the application has no good options. 2PC was designed for trusted homogeneous environments and does not survive the realities of distributed microservices over unreliable networks with third-party providers.

Q: What are the five main alternatives to 2PC in microservices?

The five families are: (1) Saga — decompose the operation into local transactions each with a compensating action, relaxes atomicity to eventual consistency with compensation; (2) Try-Confirm-Cancel (TCC) — every participant exposes Try, Confirm, and Cancel operations, the coordinator calls Try on all participants then Confirm if all succeed or Cancel if any fail; (3) Outbox — write the database update and the outgoing event to the local database in a single transaction, a separate relay forwards events to the broker with at-least-once delivery; (4) Reservation-Then-Commit — for scarce inventory, split into a Reserve phase with TTL and a Commit phase, the TTL bounds the lock-up window; (5) Idempotency-with-Retry — make every public operation idempotent so retries on network errors are safe. Production systems compose four of these (orchestration saga + outbox + reservation-then-commit + idempotency) for most cross-service operations.

Q: How does Try-Confirm-Cancel differ from 2PC?

TCC has the same two-phase structure as 2PC (prepare then commit-or-abort) but with three crucial differences. First, Try is a business-logic reservation (authorise the funds, hold the room, write a pending credit) rather than a database-level lock — this removes the XA dependency because Try can be implemented in any storage technology. Second, the reservation created by Try has a TTL — if the coordinator crashes between Try and Confirm, the participant automatically cancels the reservation when the TTL fires, so the system does not block indefinitely. Third, Confirm and Cancel are explicitly idempotent and must always succeed given a valid reservation — they cannot have business-failure modes, only transient infrastructure failures that retry will resolve. TCC delivers near-2PC semantics with none of XA, blocking-on-coordinator-failure, or homogeneity constraints, at the cost of every participant explicitly designing and maintaining three operations per business action.

Q: When should I use TCC versus an orchestration saga?

Use TCC when the business genuinely requires that either all participants commit at the same logical instant or none commit — high-value money transfers across regulated systems, multi-vendor travel bookings where the customer must be told a single yes-or-no answer, cross-system inventory commits where overselling has hard liability. Use orchestration saga (the default for everything else) when eventual consistency with compensations is acceptable — most checkout flows, multi-step provisioning, customer-onboarding workflows. The test: if a few-second window where some participants have committed and others have not is acceptable provided compensations run cleanly on failure, choose saga. If that window is unacceptable for business or regulatory reasons, choose TCC. Most operations described as "needing atomicity" actually tolerate eventual consistency once the failure case is properly analysed.

Q: Why does every saga need outbox and idempotency underneath?

Without outbox, the saga has the dual-write problem at every event-emitting step: the local commit succeeds, then the broker publish fails (or the reverse), and the saga state diverges from the broker state. Outbox reduces this to a single local transaction by writing both the state change and the outgoing event to the local database atomically, then having a separate relay process forward to the broker with at-least-once delivery. Without idempotency, the orchestrator-driven retries produce duplicate effects — the saga retries a failed payment step on a transient network error, but the original payment actually succeeded and the user has no idea, so they get charged twice. Idempotency keys on every public API let the orchestrator retry safely because the server detects the duplicate and returns the original result without re-executing. The two patterns together form the foundation under every production saga; "saga without outbox and idempotency" is functionally a misconfiguration.

Q: What is the difference between orchestration and choreography sagas?

In orchestration saga, a central coordinator (Temporal, AWS Step Functions, Camunda, a custom NestJS state machine) drives the workflow — it knows the sequence of steps, calls each service in turn, decides what to compensate on failure, and persists the workflow state durably. Failure handling is explicit and centralised. In choreography saga, there is no central coordinator — each service reacts to events published by the previous step and emits its own events for the next step to consume. There is no single place that knows what the workflow is doing; the workflow logic is distributed across many services and event handlers. Orchestration is the default for non-trivial workflows because it makes failure handling auditable and the workflow itself readable in one place. Choreography is appropriate for simple flows where the workflow has natural service-by-service event handoffs and centralised visibility is not required. Most production systems use orchestration; choreography sounds appealing in principle but produces operational pain at scale because "what failed and what was compensated" is genuinely hard to reconstruct.

Q: How does reservation-then-commit fit into the saga pattern?

Reservation-then-commit is the right primitive for any saga step that touches scarce inventory. A naive saga step that decrements stock by two cannot be cleanly compensated — between the decrement and the compensation, some other transaction may have observed the lower count and made decisions based on it, so the compensation has to deal with downstream effects that have already propagated. The right primitive is "reserve two units with a TTL"; if the saga succeeds, the saga's confirm step converts the reservation to a permanent decrement; if the saga fails, the compensation is to release the reservation, which is a clean reversal because the units were never permanently sold. Reservation-then-commit makes saga compensations substantially cleaner because the compensable step is built into the reservation lifecycle. This is true for inventory (seats, rooms, GPU capacity), payment (authorise then capture is exactly reservation-then-commit), and any other scarce resource where overselling has consequences.

Q: What are the most common anti-patterns when implementing 2PC alternatives?

Four anti-patterns recur. (1) Choosing 2PC because "we need atomicity" without analysing whether eventual consistency with compensation would actually satisfy the requirement — most business operations tolerate a short window of inconsistency provided failures are handled cleanly. (2) Emulating 2PC via "manual commit and rollback" without a coordinator log — works when everything succeeds, fails catastrophically when the orchestrating process crashes mid-flight because no record exists of what was committed and what was not; if you find yourself writing this code, introduce the durable log explicitly and adopt the saga vocabulary. (3) Building a saga without idempotency on participants — the orchestrator retries produce duplicate charges and duplicate inventory decrements, surfacing as month-end reconciliation discrepancies. (4) Holding database locks across saga steps to "tighten" the saga — recreates the 2PC blocking problem inside the saga; the right pattern is reservation-then-commit on each step, not database-level locks held across steps.

Q: What tooling supports the saga + outbox + reservation + idempotency stack in production?

For orchestration, Temporal is the leading open-source choice with durable workflows in TypeScript, Go, Java, Python; AWS Step Functions is the managed alternative on AWS; Camunda and Zeebe are popular in the Java ecosystem; custom NestJS state machines with a Postgres event log work for simpler needs. For outbox, Debezium is the canonical change-data-capture relay (tails Postgres WAL, MySQL binlog, or MongoDB oplog and publishes to Kafka); simpler implementations use a polling relay query (SELECT ... FROM outbox WHERE published = false). For reservation-then-commit, Redis with Lua scripts is the high-throughput choice (atomic decrement-and-hold with TTL); a Postgres reservations table with serialisable transactions is sufficient for up to a few thousand reservations per second. For idempotency, a Redis or DynamoDB store keyed by idempotency-key with a 24-hour TTL is the standard implementation; many API frameworks (NestJS interceptors, Express middleware) provide off-the-shelf implementations.

Q: When do I not need any of these distributed-transaction patterns?

Three cases. (1) The business operation lives inside a single service and a local database transaction is sufficient — the distributed-transaction patterns exist to handle cross-service operations, so using them inside a single service is over-engineering. (2) The operation is genuinely fire-and-forget — a successful response to the user is required, but downstream propagation can happen asynchronously with at-least-once delivery and no rollback requirement; a single event published to a broker is sufficient, no saga needed. (3) The operation tolerates a wider consistency window than these patterns provide — back-office work like commission calculations, internal financial reporting, periodic compliance reports may be fine with hourly or daily reconciliation jobs. Do not over-engineer reconciliation-tolerant operations with saga patterns they do not need. The patterns are valuable for cross-service user-facing operations that require predictable failure semantics; they are inappropriate for everything else.