2PC vs Saga vs TCC — Distributed Transactions

One transaction, many services

A single business action — “place an order” — may touch Order, Payment, and Inventory services, each with its own database. There’s no single COMMIT across them. Three patterns reconcile this, trading consistency, locking, and complexity differently.

Two-Phase Commit (2PC) — strong, but blocking

A coordinator runs two phases: Prepare (every participant locks resources and votes “ready”), then Commit (if all voted yes, everyone commits; otherwise everyone aborts). It gives ACID across services — but it’s synchronous and blocking: if the coordinator crashes after Prepare, participants sit holding locks, unable to proceed. That fragility is why 2PC is avoided in high-scale systems.

Saga — local transactions + compensation

A Saga replaces the distributed lock with a sequence of local transactions, each with a compensating transaction that semantically undoes it. If step 3 fails, you run the compensations for steps 2 and 1 (refund, release stock). Two flavours: choreography (services react to each other’s events) and orchestration (a central coordinator drives the steps). No locks, no blocking — but only eventual consistency and no isolation, so you must design idempotent steps and handle intermediate states.

TCC (Try-Confirm-Cancel) — explicit reservations

TCC splits each step into Try (reserve resources — e.g. hold the stock, authorize but don’t capture payment), then Confirm (commit the reservation) or Cancel (release it). It gives more control than a Saga and avoids 2PC’s locks, at the cost of building three operations per service.

Choosing

	2PC	Saga	TCC
Consistency	Strong (ACID)	Eventual	Eventual, reservation-based
Locking	Holds locks across the txn	None (compensations)	Soft reservation
Failure mode	Coordinator crash blocks participants	Compensations may be complex	More code, explicit cancel paths
Best for	Few services, short txns, strict ACID	Microservices, long-running flows	When you need isolation-ish reservations

Takeaways

• 2PC: strong consistency, but synchronous and blocking — doesn’t scale across many services.
• Saga: the microservices default — local txns + compensations, eventual consistency, needs idempotency.
• TCC: Saga with explicit reserve/confirm/cancel when you need tighter control.
• Reliably emitting the events that drive a Saga is the job of the Transactional Outbox pattern.

---

Re-authored for this guide. Formulas are standard public-domain engineering math (Bloom 1970; Lamport/Ongaro–Ousterhout for consensus; Gray for 2PC). Diagrams adapted from Karan Pratap Singh’s System Design (MIT) and concepts from Designing Data-Intensive Applications.

I just read a lesson on **2PC vs Saga vs TCC — Distributed Transactions** (System Design) and want to truly understand it. Explain 2PC vs Saga vs TCC — Distributed Transactions from first principles using ONE vivid real-world analogy and a visual mental model — draw it as ASCII art or a clear step-by-step diagram — with a concrete example using real numbers. Then ask me one question to check I got the mental picture, and wait for my reply. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Teach me **2PC vs Saga vs TCC — Distributed Transactions** interactively. Ask me ONE guiding question at a time, wait for my answer, and adapt to my confusion — build the idea with me step by step instead of explaining it all at once. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Quiz me on **2PC vs Saga vs TCC — Distributed Transactions** with 5 questions, easy to tricky, ONE at a time. Tell me if each answer is right; at the end, explain clearly what I got wrong and why. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Help me remember **2PC vs Saga vs TCC — Distributed Transactions** for the long term: give the one-sentence intuition, a memorable hook/mnemonic, a tiny worked example, and 3 active-recall flashcards (Q -> A). If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.