A team is designing a checkout flow that needs to debit a payment account, decrement inventory, and create a shipping order across three separate services. They're deciding between wrapping the whole thing in a two-phase-commit (2PC) distributed transaction versus using a Saga (a sequence of local transactions with compensating actions to undo earlier steps if a later one fails). What factors should drive that decision, and what does each approach give up?

## Where the cost lands The choice between two-phase commit and a Saga is really a choice about where you're willing to pay a cost: | | 2PC | Saga | |---|---|---| | **Pays with** | availability and latency | a temporary, visible inconsistency window | | **To buy** | strict, immediate atomicity and isolation | availability, latency, and looser coupling between participants | ## How each one works **Mechanism recap for context.** - **2PC** coordinates all participants to vote and then commit or abort together — the defining property is that no partial state is ever externally visible: either the payment debit, inventory decrement, and shipping order all become visible atomically, or none do, and locks held during the prepare window prevent anyone from observing or corrupting the in-flight state. - **A Saga** instead commits each local step as its own independent transaction, immediately visible, and only reacts after the fact if a later step fails: it invokes compensating actions (a refund, a restock) to semantically — not literally — undo the already-committed earlier steps. **Compensation is not a rollback** in the database sense; it's a new forward-moving transaction that tries to cancel the effect of a previous one, and it has to be designed case by case (refunding a payment is a new debit/credit that reverses the net effect, not an undo). ## What each side gives up **The core trade-off: isolation and blocking versus visibility and resilience.** - Because 2PC holds locks across the network round trip to every participant, its latency is bounded by the slowest participant and network hop, and if any one participant (or the coordinator) is unavailable, the whole transaction stalls and already-prepared participants sit holding locks, which can freeze unrelated work on those systems too. - A Saga has no analogous blocking window: each step commits and moves on, so a failure late in the sequence doesn't lock earlier resources — it just triggers compensations. This makes Sagas dramatically more tolerant of one participant being slow or briefly unavailable, and is a major reason they're preferred for workflows spanning many services, especially ones owned by different teams or companies (a travel booking that reserves a flight, a hotel, and a rental car — you cannot 2PC-lock an airline's reservation system). ## What a Saga actually costs The real cost of a Saga is that intermediate states are genuinely visible, not just theoretically. Between the payment debit committing and the inventory decrement committing, another process reading the order or the inventory count can observe a state that will later turn out to have been transient. Handling this requires either: - designing consumers to tolerate transience (an order status of 'processing' rather than treating partial state as final), or - adding a semantic reservation step (inventory gets a soft 'reserved' hold rather than a hard decrement, itself a smaller-scoped local transaction). Compensations also have their own correctness burden: they must be **idempotent**, since retries happen, and they must account for side effects that already escaped the system boundary — you can refund a payment, but you can't un-send a 'your order shipped' email, so Saga design often sequences externally-visible, hard-to-compensate steps last, after every compensable step has succeeded. ## Choosing between them **When to pick which.** - **2PC** (or, more realistically, an XA-style transaction) is right when all participants are within a trusted, low-latency boundary (two tables in the same database, or a small number of internal systems supporting the same commit protocol) and the business genuinely cannot tolerate even a brief inconsistent window — financial ledger postings inside a single bank's core system are a classic case. - **A Saga** is right once you're crossing service or organizational boundaries, involve external/third-party systems that will never implement a 2PC-compatible prepare phase, need to tolerate individual participant slowness without freezing the whole workflow, or are dealing with a genuinely long-running process (multi-day shipping fulfillment) where holding database locks for the duration is a non-starter regardless of protocol. In practice, most modern microservice architectures default to Sagas for cross-service business transactions specifically because 2PC's blocking and all-participants-must-speak-the-protocol requirements don't survive contact with independently deployed, independently owned services — 2PC largely survives only within a single database engine's own internal multi-shard commits (e.g., Google Spanner, CockroachDB) where the 'participants' are all under one operator's control and one consistent protocol stack.