Why a Single Order Triggers a Distributed Transaction (2PC, TCC, Saga Explained)

01 Local vs. Distributed Transactions

If all operations (create order, deduct inventory, submit transaction) reside in one database, the database guarantees atomicity: either all succeed or all fail. This is a local transaction.

In real micro‑service systems each domain (order, inventory, payment, points, coupon) often has its own service and database. When one step succeeds and another fails—e.g., order created but inventory deduction fails—the system faces inconsistency, illustrating why distributed transactions are hard.

02 Goal of Distributed Transactions

A distributed transaction aims to ensure a group of operations across multiple services/databases either all succeed or can be compensated to achieve business consistency.

Not every scenario needs strong consistency every second. Some, like payment, inventory, and deduction, require strong consistency; others, like points, notifications, and logs, can tolerate eventual consistency.

The article introduces three common solutions: 2PC, TCC, and Saga.

03 Two‑Phase Commit (2PC)

2PC works like a team leader asking everyone if they are ready. The coordinator first asks all participants to Prepare / Vote. Participants lock resources, write logs, and reply Yes or No. In the second phase the coordinator either Commit if all said Yes, or Rollback if any said No.

04 Advantages and Problems of 2PC

Strong consistency and clear logic; suitable for high‑consistency, low‑concurrency scenarios such as traditional DB transactions and financial systems.

Drawbacks: blocking (resources stay locked while waiting), single‑point risk of the coordinator, and poor performance due to multiple network round‑trips, making it unsuitable for high‑throughput internet services.

05 Try‑Confirm‑Cancel (TCC)

TCC lets each service expose three actions: Try (reserve resources), Confirm (finalize), and Cancel (release). Example for order‑inventory:

Try : freeze 1 item of inventory, create a pending order, reserve a coupon.

Confirm : permanently deduct inventory, mark order as paid, use the coupon.

Cancel : unfreeze inventory, cancel the order, release the coupon.

06 When TCC Fits

Suitable for scenarios that need explicit reservation and confirmation, such as order creation, inventory deduction, payment, coupon usage, and other resource‑reservation workflows.

Advantages: business control, no long‑term locks, stronger than pure compensation.

Disadvantages: high code intrusion (each service must implement three interfaces) and pitfalls like empty rollback, idempotency, and hanging.

07 Saga Pattern

Saga breaks a large distributed transaction into a series of local transactions, each paired with a compensating action. If a later step fails, previously successful steps are undone in reverse order.

Example order flow:

Create order → compensation: cancel order.

Complete payment → compensation: refund.

Create logistics record → compensation: cancel logistics.

Grant points → compensation: deduct points.

If the logistics step fails, the system refunds and cancels the order.

08 When Saga Fits

Long business processes spanning multiple services.

Scenarios that can tolerate eventual consistency.

When holding resources for a long time is undesirable.

Advantages: no long‑term locks, good scalability for long flows.

Drawbacks: complex compensation logic, cannot guarantee strong consistency, intermediate states may be briefly visible to users.

09 Comparing 2PC, TCC, Saga

2PC: vote first, commit only if everyone agrees – best for strong‑consistency, low‑concurrency cases.

TCC: reserve‑then‑confirm‑or‑cancel – best for resource‑reservation scenarios like ordering, inventory, payment, coupons.

Saga: step‑by‑step with compensations – best for long‑running workflows where eventual consistency is acceptable.

10 Quick Visual Summary

Distributed transaction → multiple services cooperate → problem: partial success.

2PC: coordinator asks all participants, all Yes → commit; any No → rollback.

TCC: Try (reserve) → Confirm (finalize) or Cancel (release).

Saga: execute local transactions sequentially, on failure run compensations in reverse order.

11 Exam Answer Example

For an e‑commerce order that needs to create an order, deduct inventory, reserve a coupon, and complete payment, the appropriate solution is TCC because it handles resource reservation and guarantees idempotent Confirm/Cancel handling.

12 Key Takeaways

Distributed transaction = group of operations across services/databases that must be all‑or‑nothing or compensated.

2PC = Prepare/Vote + Commit/Rollback – strong consistency, low performance.

TCC = Try/Confirm/Cancel – resource reservation, good for ordering, inventory, payment.

Saga = Local transaction + compensation – suited for long flows, eventual consistency.

13 Self‑Test

What are the two phases of 2PC?

What do the three letters of TCC stand for?

What is the core idea of Saga?

Is order‑inventory more suitable for TCC or Saga?

Which pattern matches a long‑process that needs reverse compensation?

If you can answer these in your own words, you have passed Day 2.

Conclusion

Distributed transactions are not just abstract concepts; they solve the real problem of coordinating multiple systems to achieve a consistent business outcome. Remember the three patterns and their typical scenarios, and you’ll be able to select the right tool when faced with exam questions or real‑world designs.