Distributed Transactions: Consistency Theory and Practical Solutions

In the era of widespread distributed systems, distributed transactions are an unavoidable topic; this article discusses consistency issues and practical solutions for distributed transactions.

Why Distributed Transactions Are Needed

Rapid growth of internet traffic has made centralized architectures insufficient, leading to data and service partitioning by business units and the shift to service‑oriented distributed applications, exemplified by Alibaba's Taobao splitting databases for products, orders, users, and stores.

When a business operation such as purchasing a product requires updates across multiple services (order, inventory, payment), these actions must be performed within a single transaction to ensure data consistency.

Distributed Consistency Theory

The CAP theorem, proposed by Eric Brewer, states that a distributed system cannot simultaneously guarantee Consistency, Availability, and Partition Tolerance.

Consistency (C)

Availability (A)

Partition tolerance (P)

In most scenarios, strong consistency is sacrificed for high availability, leading to eventual consistency.

BASE Theory

BASE (Basically Available, Soft state, Eventually consistent) evolves from CAP, acknowledging that while strong consistency may be unattainable, systems can aim for eventual consistency based on business needs.

Distributed Transaction Solutions

1. XA Protocol – Two‑Phase Commit (2PC)

XA separates transaction management into a global transaction manager and local resource managers (typically databases). The protocol consists of a voting phase and a commit/rollback phase.

Advantages: Ensures strong data consistency with relatively low implementation cost; widely supported by major databases.

Disadvantages: Single‑point‑of‑failure risk, performance overhead, and cross‑database challenges.

2. Transaction Compensation – TCC Model

TCC refines 2PC by splitting each business branch into Try, Confirm, and Cancel operations, reducing lock contention and improving throughput, though it introduces code intrusion.

Example: Ant Financial's DTS (prepare, commit, rollback).

3. Message‑Queue Based Eventual Consistency

By decoupling services through asynchronous messaging middleware, systems achieve eventual consistency; implementations include RocketMQ, RabbitMQ, and transactional messages in newer Kafka versions.

Overall, distributed transaction design balances CAP trade‑offs, and the appropriate solution depends on business requirements, development resources, and the chosen technology stack.