Why Distributed Transactions Matter: Concepts, Scenarios, and Solutions

1. What Is a Distributed Transaction?

A distributed transaction spans multiple independent databases or services, requiring all participating operations to either commit together or roll back together, thus guaranteeing data consistency across different nodes.

2. Why Distributed Transactions Appear

When a system grows and adopts sharding (splitting tables across databases) or service‑oriented architecture (SOA), a single business operation may need to touch several databases. For example, splitting an e‑commerce platform into separate product, order, user, and inventory services creates the need for cross‑database consistency.

3. ACID Properties of Transactions

Atomicity (A) : All steps succeed or none are applied.

Consistency (C) : The system moves from one valid state to another; e.g., a transfer of $50 from account A to B always results in A‑$50 and B+​$50.

Isolation (I) : Concurrent transactions do not interfere with each other; intermediate states are invisible.

Durability (D) : Once committed, changes survive crashes or power loss.

4. Typical Application Scenarios

Payments : Debit buyer’s account and credit seller’s account must succeed together.

Online Order Placement : Decrease inventory and update order status reside in different databases and must be consistent.

5. Common Distributed Transaction Solutions

5.1 Two‑Phase Commit (2PC) Based on XA Protocol

2PC uses a coordinator to manage participants through a prepare phase and a commit/rollback phase, ensuring ACID across nodes. The algorithm:

Coordinator asks participants if they can commit.

Participants lock resources, write undo/redo logs, and reply “yes” or “no”.

If all say “yes”, coordinator sends a commit command; otherwise it sends a rollback.

XA implementations exist in Oracle, DB2, and some commercial databases. However, performance suffers under high concurrency, and MySQL’s XA lacks a proper prepare‑log, limiting reliability.

5.2 Message‑Based Transaction + Eventual Consistency

This pattern treats the message broker as a two‑phase commit: the local transaction and the message send are bundled. If both succeed, the overall operation is considered committed; otherwise both are rolled back. RocketMQ provides this capability.

Typical steps:

A system sends a provisional message to the broker.

Broker stores the provisional message and acknowledges.

A executes its local transaction.

A sends a commit message; the broker finalizes the message.

If any step fails, appropriate rollback or compensation logic is triggered. This approach improves performance but sacrifices strict consistency for eventual consistency.

5.3 TCC (Try‑Confirm‑Cancel) Model

TCC splits a business operation into three phases:

Try : Perform all checks and reserve required resources (e.g., lock accounts).

Confirm : Execute the actual business logic using the reserved resources; operations must be idempotent.

Cancel : Release reserved resources if the confirm phase fails, possibly with compensation retries.

TCC is essentially a programmable variant of 2PC, offering flexibility but requiring custom code for each business scenario.

6. Summary

Distributed transactions coordinate multiple databases to maintain consistency. Solutions range from strict two‑phase commit (high consistency, low performance) to looser eventual‑consistency patterns (higher throughput). The choice depends on business requirements for consistency versus performance.