Distributed Transactions: Fundamentals, CAP & BASE Theories, and Solution Comparisons

Distributed transactions are essential for modern micro‑service architectures where a single business operation spans multiple services or databases.

1. Basic Concepts

A transaction is an atomic unit of work that must either fully succeed or fully fail. The ACID properties (Atomicity, Consistency, Isolation, Durability) describe the guarantees of a local database transaction.

2. Distributed Transactions

When services communicate over a network, a transaction may involve remote calls, leading to distributed transactions. The article shows simple SQL‑like examples of local and distributed transaction scripts wrapped in begin transaction; … commit transaction; .

2.1 CAP Theory

CAP (Consistency, Availability, Partition tolerance) explains that a distributed system can satisfy at most two of the three properties. The article illustrates each property with an e‑commerce example and discusses the three possible CAP combinations (AP, CP, CA) and their implications for transaction design.

2.2 BASE Theory

BASE (Basically Available, Soft state, Eventually consistent) extends CAP by accepting eventual consistency in exchange for higher availability, describing how “soft” states and eventual consistency are used in practice.

3 Distributed‑Transaction Solutions

3.1 Two‑Phase Commit (2PC)

2PC splits a transaction into a Prepare phase and a Commit phase. The article uses a simple payment example and outlines the roles of Transaction Manager (TM), Resource Manager (RM), and Application Program (AP). It also lists the drawbacks of 2PC (blocking, performance).

3.2 XA Scheme

XA is the database‑level implementation of 2PC. The article provides a step‑by‑step flow for a new‑user‑registration scenario, showing how the TM coordinates RM actions.

3.3 Seata Scheme

Seata is an open‑source middleware that implements 2PC at the application layer, reducing lock time by committing local branches in the first phase. The architecture includes Transaction Coordinator (TC), Transaction Manager (TM), and Resource Manager (RM). A detailed flow for a user‑registration and points‑addition use case is presented.

3.4 TCC (Try‑Confirm‑Cancel)

TCC requires each branch to implement three operations: Try (resource reservation), Confirm (final commit), and Cancel (rollback). The article explains the TCC workflow, common pitfalls (empty rollback, idempotency, hanging), and provides Java‑style pseudo‑code for a money‑transfer example.

3.5 Reliable Messaging (Final Consistency)

Reliable messaging ensures that a local transaction and a message are atomically persisted. The article describes the local‑message‑table pattern and RocketMQ transactional messages, including the executeLocalTransaction and checkLocalTransaction callbacks.

3.6 Maximum‑Effort Notification

This lightweight approach uses MQ acknowledgment to retry notifications until the receiver acknowledges, with a fallback query mechanism for eventual consistency.

4 Comparison

A table summarizes the trade‑offs among 2PC, TCC, reliable messaging, and maximum‑effort notification in terms of consistency, throughput, and implementation complexity.

Overall, the article advises preferring single‑database local transactions when possible, and selecting the appropriate distributed‑transaction pattern based on the specific consistency, performance, and operational requirements of the system.