Why Distributed Transactions Matter: From CAP Theorem to XA, 2PC, 3PC and TCC

1.1 Development of Distributed Systems

Early centralized systems were monolithic, making them hard to scale, deploy, and maintain. The rise of micro‑service architectures split applications into independent services that collaborate to fulfill complex business processes while appearing as a single system to users.

Distributed systems can be decomposed in several ways:

Business modules can be split by domain, each with its own API, service, and data layers, or by client type (mobile, desktop, web).

Data storage can be partitioned into multiple database instances, with further sharding at the table level.

Middleware such as distributed caches, search services, NoSQL databases, file services, and message queues ensure availability and reliability.

1.2 Advantages and Disadvantages

Distributed systems provide scalability, independent service governance, and improved reliability, especially with modern micro‑service frameworks (Spring Cloud, Dubbo) and container platforms (Kubernetes, Docker). However, they introduce complexity: distributed transactions, locks, sessions, and data consistency become challenging, increasing development, testing, deployment, and operational costs.

2.1 Using Distributed Transactions to Solve Problems

A distributed transaction involves multiple independent resources participating in a single global transaction, ensuring that all actions either commit together or roll back together to maintain atomicity and data consistency across nodes.

2.2 CAP Theorem

The CAP theorem states that a distributed system can simultaneously guarantee at most two of the following three properties:

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

Availability : every request receives a response, regardless of success.

Partition Tolerance : the system continues to operate despite network partitions.

In practice, most systems prioritize partition tolerance and choose either CP (strong consistency) or AP (eventual consistency).

2.3 Distributed Transaction Application Scenarios

2.3.1 Typical Payment Scenario

Payments require atomic debit and credit operations across different platforms and databases, necessitating distributed transactions.

2.3.2 Online Order Scenario

Order placement must atomically deduct inventory and update order status, often involving separate databases.

2.3.3 Cross‑Bank Transfer Scenario

Transferring funds between banks involves distinct platforms and databases, requiring distributed transactions to ensure both debit and credit succeed together.

3.1 XA Two‑Phase Commit Protocol

The two‑phase commit (2PC) protocol ensures all participants reach a consistent outcome. In the prepare phase, the coordinator asks each participant if it can commit; any failure triggers a rollback. In the commit phase, if all participants agree, the coordinator instructs them to commit; otherwise, it rolls back.

3.2 XA Three‑Phase Commit (3PC)

3PC adds a pre‑commit phase between the prepare and commit phases, introducing timeout mechanisms for both coordinator and participants. This reduces the impact of coordinator failures but adds complexity and performance overhead.

3.3 MQ Transaction

Using message queues to asynchronously complete the second half of a transaction achieves eventual consistency while avoiding the performance penalties of XA protocols.

3.4 TCC Transaction

TCC (Try‑Confirm‑Cancel) follows a similar three‑step pattern to XA but is implemented at the business logic level. It is suitable for scenarios requiring strong consistency, such as e‑commerce order processing, cross‑bank transfers, and distributed resource reservation.

Try: check business feasibility and reserve resources.

Confirm: execute the business operation if Try succeeded.

Cancel: roll back if Try failed or timed out.

3.5 Final Compensation Mechanism (Dead‑Letter Queue)

When a message is produced successfully but consumption fails, it is placed in a Dead‑Letter Queue. A separate job service can reprocess these messages to ensure eventual consistency.

Dead-Letter Queue

Summary

This article introduced the fundamentals of distributed systems and presented various solutions—XA 2PC/3PC, MQ‑based transactions, TCC, and compensation mechanisms—to ensure data consistency and atomicity in distributed transaction scenarios.