Mastering Distributed Transactions: 8 Powerful Techniques Explained

1. Introduction

In the previous article we discussed two essential theories for distributed systems: the CAP theorem and the BASE theorem.

Time machine: Deep Dive into Distributed, CAP and BASE

Today we explore the “Eight Magic Techniques” for distributed transactions to help you apply them in real systems.

2. Common Distributed Transaction Solutions

Distributed transactions span multiple nodes and must preserve ACID properties, which is challenging. The industry has eight typical solutions, known as the “Eight Magic Techniques”.

Technique 1) 2PC

Two‑phase commit (2PC) is a strong consistency protocol with a prepare phase and a commit phase.

In the prepare phase the coordinator asks all participants if they are ready; if all agree, the commit phase notifies them to commit. If any participant cannot prepare, the coordinator aborts.

Advantages:

Atomicity guarantee: All participants either commit or roll back.

Simple and intuitive: Clear logic, widely adopted (e.g., MySQL since 5.5).

Disadvantages:

Synchronous blocking: Participants wait during the commit phase, leading to long lock times under high concurrency.

Single‑point failure: If the coordinator crashes in the second phase, participants may wait indefinitely.

Data inconsistency: Network loss of commit messages can cause some participants to roll back while others commit.

Complex recovery: Recovery requires participants to retain sufficient state.

Technique 2) 3PC

Three‑phase commit (3PC) improves on 2PC by adding a pre‑commit phase with timeout handling, reducing blocking and single‑point failure risk.

CanCommit phase: Coordinator sends CanCommit request; participants reply Yes or No.

PreCommit phase: If all reply Yes, coordinator sends PreCommit; participants write logs and ACK.

DoCommit phase: After all ACK, coordinator sends commit.

Compared with 2PC, 3PC introduces timeout in the pre‑commit phase, allowing participants to abort if they do not receive a final instruction.

Typical scenarios include distributed databases, telecom billing systems, and large cloud platforms where high reliability and low lock time are required.

Considerations: higher complexity, extra network overhead, and still vulnerable in extreme partitions.

Technique 3) TCC

Try‑Confirm‑Cancel (TCC) splits a transaction into three application‑level steps: Try reserves resources, Confirm executes the business if all tries succeed, Cancel rolls back reserved resources on failure.

Example: buying a train ticket – Try checks wallet and locks funds, Cancel releases resources on failure, Confirm finalizes the purchase.

Advantages: solves single‑point failure, data inconsistency, and blocking by using multiple activity managers, timeout compensation, and fine‑grained resource control.

Technique 4) Saga

Saga breaks a long‑running transaction into a series of local transactions linked by asynchronous messages. If a step fails, compensating actions roll back previous steps.

Example: travel booking – separate local transactions for flight, hotel, and car rental; if car rental fails, previous bookings are cancelled.

Pros: flexibility, reduced lock time, fault tolerance, suitable for microservices.

Cons: added complexity, only eventual consistency, difficult compensations, testing challenges.

Technique 5) Distributed Lock

Distributed locks (e.g., via Redis or ZooKeeper) ensure that multiple nodes do not concurrently modify the same resource, useful in scenarios like flash‑sale inventory control.

Technique 6) Local Message Table

A local message table records asynchronous remote calls within the same database transaction, guaranteeing atomicity between the local transaction and the message. A background worker later publishes pending messages to a queue.

This approach, introduced by eBay, implements BASE theory and eventual consistency while requiring idempotent handling.

Technique 7) Reliable Message Transaction

Reliable message services send a “prepare” message, execute the local transaction, then commit or roll back the message based on the transaction outcome. Consumers retry on failure. Alibaba’s RocketMQ is a typical implementation.

Technique 8) Best‑Effort Notification

Best‑effort notification attempts to inform other participants after a local transaction succeeds, without guaranteeing 100 % delivery. Failures are logged and may require manual intervention.

3. Summary

Choosing a distributed‑transaction solution requires balancing consistency, performance, and complexity. 2PC/3PC suit scenarios demanding strong consistency; TCC fits fine‑grained control in complex business flows; Saga, local message tables, reliable messages, and best‑effort notifications are appropriate when eventual consistency is acceptable.