Distributed Transactions Explained: CAP Trade‑offs and Practical 2PC, TCC, and MQ Solutions

What Is a Distributed Transaction

A distributed transaction occurs when a single logical operation spans multiple independent systems that must coordinate over a network to achieve atomicity, consistency, isolation, and durability.

Distributed System

A system deployed across different nodes that interact via network to complete collaborative work, such as a recharge‑and‑points service where the payment system and points system must cooperate.

Transaction Basics

A transaction is a unit of work composed of several operations that guarantees the ACID properties:

Atomicity – all operations succeed or all are rolled back.

Consistency – data moves from one correct state to another.

Isolation – intermediate changes are invisible to other transactions until commit.

Durability – committed changes survive crashes.

Local vs. Distributed Transactions

Local transactions are managed by a single relational database with built‑in ACID support. Distributed transactions involve multiple systems (or multiple data sources) that must coordinate, even if they access the same database.

CAP Theory and Its Impact on Distributed Transactions

The CAP theorem states that a distributed system can simultaneously satisfy at most two of the three guarantees: Consistency, Availability, and Partition Tolerance.

Consistency : All nodes see the same data at the same time.

Availability : Every request receives a response, even if some nodes fail.

Partition Tolerance : The system continues operating despite network partitions.

Because partition tolerance is unavoidable, designers must choose between consistency and availability. In practice, most systems adopt the AP combination, sacrificing strong consistency for higher availability and eventual consistency.

Practical Distributed‑Transaction Solutions (Three Examples)

Two‑Phase Commit (2PC)

2PC introduces a coordinator that orchestrates participants through a prepare phase and a commit/rollback phase to preserve ACID across nodes.

Prepare Phase : The coordinator sends a Prepare request; each participant logs undo/redo information locally and replies with success or failure.

Commit Phase : If all participants responded positively, the coordinator sends Commit; otherwise it sends Rollback. Participants then finalize or revert their local changes and release locks.

Drawbacks of 2PC include synchronous blocking, a single point of failure at the coordinator, potential data inconsistency if a failure occurs after some participants have committed, and the inability to resolve ambiguous states when both coordinator and a participant crash.

Transaction Compensation (TCC)

TCC builds on 2PC at the business‑logic layer with three explicit steps: Try, Confirm, and Cancel.

Try : Reserve necessary resources and perform preliminary checks.

Confirm : Execute the actual business operation once all tries succeed.

Cancel : Release reserved resources if any try fails.

Advantages are strong eventual consistency and flexibility; disadvantages are higher development cost because each participant must implement three idempotent interfaces.

Message‑Queue Based Eventual Consistency

This approach decomposes a distributed transaction into multiple local transactions coordinated asynchronously via a message queue.

Order and inventory services perform checks and reserve resources.

The order service records the order and publishes a “reduce‑stock” message within a local transaction.

A scheduled task reads the message and notifies the inventory service.

The inventory service reduces stock, records the message status, and ensures idempotence.

Upon completion, the inventory service sends a confirmation message back.

The order service removes the pending message after receiving confirmation.

Benefits include higher performance and lower development effort compared to TCC; drawbacks are increased database read/write traffic and sub‑optimal suitability for very high‑concurrency scenarios.

Conclusion

The article outlines the core concepts of distributed transactions, explains how CAP constraints shape design choices, and compares three concrete implementation patterns—2PC, TCC, and a message‑queue driven eventual‑consistency model—highlighting their workflows, strengths, and limitations.