A checkout flow must debit a payment service and reserve inventory in two separate databases owned by two separate services. Compare coordinating this with a two-phase commit (2PC) protocol versus a Saga with compensating transactions, and say which you'd pick and why.

## How two-phase commit works Two-phase commit (2PC) coordinates a single atomic transaction across multiple independent databases by splitting commit into two round trips. 1. **Phase one ("prepare")** — a coordinator asks every participant — here, the payment service's database and the inventory service's database — to do everything needed to commit (validate the operation, write it to a durable log, acquire locks on the affected rows) and then reply "yes, I can commit" or "no, abort," without actually making the change visible yet. 2. **Phase two** — only once every participant votes yes does the coordinator move to phase two and tell everyone to actually commit; if any participant votes no, it tells everyone to abort instead. Because every participant has already durably promised it can commit before phase two starts, the protocol guarantees all-or-nothing: either both the debit and the reservation happen, or neither does. ## Why 2PC exists The reason 2PC exists is that it gives real atomicity across resource managers that don't share a transaction log — exactly the payment-database-versus-inventory-database situation here — without requiring you to merge them into one database. It's the same guarantee a single ACID transaction gives you inside one database, extended across a network boundary. ## What that guarantee costs That guarantee is expensive on both sides. - **The lock window.** During the window between "prepare" and "commit," every participant holds its locks — on the customer's payment row, on the inventory row — so no other transaction can touch that data, for as long as the slowest participant and the coordinator's round trip take; under load or across regions this directly throttles throughput and adds latency to every checkout. - **The blocking problem.** Worse is what happens if the coordinator crashes after collecting all the "yes" votes but before sending "commit": participants are contractually obligated to hold their locks and can't unilaterally decide to commit or abort on their own — they're "in doubt" — so they block, potentially for a long time, until the coordinator recovers and tells them what happened. This is 2PC's well-known blocking problem, and it turns a coordinator outage into an availability outage for every transaction it was midway through. - **XA outside relational databases.** On top of that, XA (the standard protocol most 2PC implementations use) is poorly supported outside traditional relational databases — most managed payment gateways, message queues, and NoSQL stores don't implement it at all, which rules 2PC out for a huge share of real microservice stacks regardless of the performance trade-off. ## How a Saga works instead A Saga takes the opposite approach: instead of one distributed transaction, it's a sequence of independent local transactions, each of which commits immediately and durably on its own database, with no cross-service locking at all. Debit payment commits and is visible right away; reserve inventory then runs as its own separate local transaction. If a later step fails — inventory is out of stock — the Saga doesn't roll anything back in the database sense; instead it runs a compensating transaction for each already-completed step, in reverse order (refund the payment), to semantically undo the effect. Sagas can be coordinated by: - **choreography** — each service publishes an event and reacts to the previous service's event, with no central coordinator; - **orchestration** — a central saga orchestrator explicitly calls each step and, on failure, explicitly calls the compensations. Orchestration is easier to reason about and debug at the cost of a new component to build and run. ## What a Saga gives up The trade-off is that Sagas give up atomicity and isolation. - There is a real window — between "payment debited" and "inventory reserved" — where the system is observably in an intermediate state; a concurrent read of the order could see a charged customer with no confirmed inventory. - Compensations also aren't true rollbacks: "refund the payment" is a new, forward-moving transaction, not an undo of the charge, and it can itself fail (the refund API times out), which pushes you into needing retries and idempotency keys on the compensations themselves, and sometimes a manual reconciliation path when compensation genuinely can't complete. - Steps also need to be designed so a partial failure never leaves unrecoverable state — e.g., reserving inventory rather than immediately decrementing it, so the compensation is a cheap "release the hold" rather than something irreversible. ## Which one to pick for this checkout For a checkout flow like this, most real systems pick the Saga, for two converging reasons: 1. payment gateways essentially never participate in XA/2PC, so 2PC is often not technically available as an option; 2. even where it is, the cross-service locking and blocking-on-coordinator-failure risk is a worse operational trade for a customer-facing, high-throughput path than the complexity of writing a "refund payment" compensation. 2PC remains the right tool in narrower cases — coordinating commits across a small number of resource managers that do support XA, within a single trusted operational boundary, where strict atomicity matters more than throughput, such as some internal financial ledger systems spanning two databases under the same team's control.