# Saga vs Two-phase commit > A saga commits local transactions step by step and uses compensating actions when the workflow cannot finish; two-phase commit (2PC) coordinates one atomic commit decision across participating transactional resources. Choose a saga for long-running workflows across independent services or external APIs, and consider 2PC for short transactions whose participants support the protocol and must commit or abort together. Source: https://sysround.com/compare/saga-vs-two-phase-commit Updated: 2026-11-05 ## Side by side | | Saga | Two-phase commit | |---|---|---| | Commit boundary | Each step commits independently | One atomic decision across participants | | Failure handling | Retry steps or compensate committed work | Abort before commit decision; recover afterward | | Intermediate state | Committed partial progress can be visible | Visibility depends on database isolation | | Resource holding | Local transactions finish between steps | Prepared participants retain locks or resources | | Coordinator failure | Durable workflow resumes after recovery | Prepared participants may block awaiting a decision | | Participant requirements | Local transactions and retry-safe business operations | Prepare/commit support and durable recovery | | External APIs | Works with reservations, refunds, and reconciliation | Cannot include APIs without protocol support | | Typical fit | Long-running business workflows | Short, tightly controlled distributed transactions | ## The differences that matter A saga changes the business model, not just the transaction mechanism. After reserving inventory and authorizing payment, another request may observe those committed states before the order finishes. Model explicit states such as PENDING, CONFIRMED, and CANCELING, and enforce local invariants with transactions or conditional writes. In 2PC, the coordinator first asks participants to prepare, then durably records a commit or abort decision and distributes it. A prepared participant has promised it can commit and cannot safely abort just because a timeout expires. If it cannot learn the decision, it may retain locks or other resources and block conflicting operations. Compensation is a new business action, not a database rollback. Releasing a reservation may restore inventory, but refunding a payment does not erase the original charge or its external effects. Compensations can also fail, so a saga needs durable progress, retries, reconciliation, and sometimes manual intervention. 2PC provides an atomic commit decision, not serializable isolation by itself. Isolation depends on the databases and concurrency-control scheme, and arbitrary reads across participants can still observe inconsistent snapshots. A saga provides no global isolation either; reservations and state guards must prevent invalid concurrent actions. Both approaches need durable recovery. A saga orchestrator records completed steps and uncertain outcomes; choreography distributes that coordination across events and handlers. When a step updates a database and publishes an event, an outbox can close that dual-write gap, while idempotent handlers make retries safe. ## Choose Saga when - The workflow includes payment providers, shipping services, or other APIs that do not participate in 2PC. - Steps involve human approval or external processing, making it impractical to hold transactional resources until completion. - The product can expose pending states and has meaningful compensating actions for completed steps. - Independent services need to commit local work without keeping a shared transaction open while other services recover. ## Choose Two-phase commit when - All participants support a compatible prepare/commit protocol and have tested durable recovery. - The requirement is atomic commit across participating resources, and compensating committed changes would not satisfy the business invariant. - Transactions are short, participant count is limited, and prepared-state resource holding is acceptable. - The operational environment can tolerate blocking during failures and provides coordinator recovery and in-doubt transaction monitoring. ## Worked example: Ticket booking with an external payment provider Suppose a booking service holds two seats for five minutes and charges $160 through an external payment API. A saga creates the seat hold, requests payment with a stable idempotency key, and confirms the booking only if the hold is still valid. If the payment response times out, it queries or reconciles the payment status rather than blindly issuing another charge. If payment succeeds after the hold expires, the workflow refunds the charge or follows an explicit recovery policy. 2PC cannot make the payment and seat update atomic unless the provider participates in its prepare/commit protocol. Seat allocation still needs a local atomic check to prevent overselling. ## In the interview - Start with the invariant: must these writes commit together, or can the business tolerate a pending workflow followed by compensation? First check whether one database transaction can cover the invariant. - Walk through a failure after each step. For a saga, explain how you distinguish a failed operation from a successful operation whose response was lost before retrying or compensating. - For 2PC, describe a participant that has voted yes and then loses contact with the coordinator. Expect questions about durable decisions, recovery, retained locks, and why a local timeout cannot justify aborting. - For a saga, name the compensation for each reversible step and identify irreversible actions. Explain reservation expiry, idempotency keys, durable timers, and when reconciliation or operator intervention is necessary. - Separate atomic commit from isolation and availability. Expect the interviewer to ask how concurrent requests affect inventory or balances, and which operations stop making progress during a partition. ## Common mistakes - Calling a saga an all-or-nothing transaction. Earlier steps have already committed, and compensation may be delayed, imperfect, or impossible. - Assuming 2PC automatically provides serializability or makes writes visible everywhere at exactly the same instant. - Treating a timeout as proof that an operation failed. A payment may have succeeded, and a prepared 2PC participant may still be bound by a commit decision. - Choosing between saga and 2PC before checking whether a single local transaction, a reservation, or a different ownership boundary removes the distributed transaction. ## Interview questions where it comes up - [Design a ticket booking system like Ticketmaster](https://sysround.com/questions/design-ticketmaster): Seat holds and payments expose the difference between local inventory atomicity and a cross-service workflow with compensation. - [Design a food delivery app like DoorDash](https://sysround.com/questions/design-doordash): Restaurant acceptance, payment, and courier assignment require durable coordination with explicit cancellation rules. - [Design a payment system](https://sysround.com/questions/design-payment-system): External payment operations usually require idempotency and reconciliation rather than assuming they can join a distributed commit. - [Design a wire transfer system](https://sysround.com/questions/design-wire-transfer-system): A strong answer separates atomic ledger updates from uncertain bank-side effects that require workflow recovery. - [Design a hotel booking system](https://sysround.com/questions/design-hotel-booking-system): Multi-night inventory must remain locally consistent while expiring holds and payment outcomes are coordinated across transaction boundaries. ## FAQ ### What is the main difference between a saga and two-phase commit? A saga commits a sequence of local transactions and compensates completed work when necessary. Two-phase commit makes a single atomic commit or abort decision across participating transactional resources. The main trade-off is business-level recovery and visible intermediate states versus tighter coordination and possible blocking. ### Is a saga always better than 2PC for microservices? No. A saga fits independent services and long-running workflows only when intermediate states and compensations are acceptable. If a strict invariant requires atomic commit across compatible resources, 2PC may be appropriate. Often the simpler solution is to place the invariant inside one transactional owner. ### Can two-phase commit block, and does a saga avoid blocking? Classic 2PC can block when a prepared participant cannot discover the coordinator's decision. A saga avoids holding one distributed transaction open across the workflow, but it can still stall while waiting for dependencies, retries, or compensation. Neither approach guarantees progress through every outage. ## Related concepts - [Saga pattern](https://sysround.com/concepts/saga-pattern) - [Two-phase commit](https://sysround.com/concepts/two-phase-commit) - [Distributed transactions](https://sysround.com/concepts/distributed-transactions) - [Idempotency and idempotency keys](https://sysround.com/concepts/idempotency) - [Transactional outbox pattern](https://sysround.com/concepts/outbox-pattern) --- SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.