From ACID to BASE: Picking the Best of 6 Distributed Transaction Strategies

ACID vs. BASE

ACID provides atomicity, consistency, isolation, and durability for single‑node databases, but when data spans multiple nodes the guarantees weaken; sharding and micro‑service decomposition break transaction boundaries. BASE (Basically Available, Soft state, Eventually consistent) and the CAP theorem explain the necessary trade‑offs between consistency and availability in distributed transactions.

Six Distributed Transaction Solutions

2PC: Two‑Phase Commit – strong consistency but blocking

In an e‑commerce order scenario, the coordinator sends Prepare requests to the order and inventory databases, which lock rows and write undo/redo logs. After all participants reply “Yes”, the coordinator issues Commit , making both order creation and inventory deduction permanent. If the coordinator crashes after the prepare phase, the participants remain locked, causing a blocking problem that can severely degrade throughput.

3PC: Three‑Phase Commit – theoretical improvement, limited practice

3PC adds a CanCommit phase before the traditional prepare, then a PreCommit phase, and finally DoCommit . In a transfer example, participants check feasibility, lock resources in PreCommit, and commit in DoCommit. However, a network partition after PreCommit can cause one side to commit while the other rolls back, leading to data inconsistency—hence 3PC is rarely used in production.

TCC: Try‑Confirm‑Cancel – business‑level compensation

Proposed by Pat Helland (2007), TCC moves consistency to the application layer. In a transfer, the Try step freezes resources, Confirm finalizes them, and Cancel releases them on failure. This approach requires three interfaces per operation, dramatically increasing code size, and the Cancel operation must be idempotent to avoid double‑unfreezing.

Saga: Long‑running transaction with compensation

Originating from Garcia‑Molina and Salem (1987), Saga splits a long transaction into a series of independent sub‑transactions. Each sub‑transaction commits immediately; if any later step fails, compensating actions are invoked in reverse order. In a travel‑booking example, flight, hotel, and car reservations are made sequentially; a failure in car rental triggers cancellation of hotel and flight bookings. Compensations are semantic rollbacks, not true state restoration, and intermediate states are visible to other services.

Local Message Table – simple eventual consistency

Derived from eBay’s practice, the pattern writes both the business record and a “message” record into the same local transaction. A background poller scans the message table, publishes pending messages to a queue (e.g., RabbitMQ), and the consumer updates the downstream service (e.g., inventory). This guarantees atomicity of business write and message creation, but introduces polling latency, database pressure, and tight coupling between business and infrastructure.

Reliable Message (Transactional Message) – decoupled eventual consistency

Using RocketMQ’s transaction‑message feature, the producer first sends a “half‑message”, then executes the local transaction (order creation). Based on the transaction outcome, it sends a Commit or Rollback to make the half‑message visible or discard it. The broker periodically checks back with the producer if the final decision is missing. This approach shifts complexity to the middleware but requires a broker that supports transactional messages and a reliable check‑back interface.

Comparison and Selection Guide

2PC – strong consistency, high lock cost, low business intrusion.

3PC – adds pre‑commit to reduce blocking but introduces consistency risks; rarely adopted.

TCC – business‑level strong consistency, very high code intrusion (three APIs per operation), requires idempotent Cancel.

Saga – eventual consistency, suitable for long‑running workflows, moderate intrusion (compensation logic).

Local Message Table – simple eventual consistency, tight coupling of business and messaging, suffers from polling delay and DB pressure.

Reliable Message – decoupled eventual consistency, depends on middleware that supports transactional messages and check‑back.

Decision flow: first determine whether eventual consistency is acceptable; if not, choose 2PC or TCC. If eventual consistency is fine, assess tolerance for business intrusion—high tolerance leads to TCC, low tolerance to Saga or message‑based solutions. Finally, consider transaction length—short chains favor 2PC or local message tables, long chains favor Saga or reliable messages.

There is no silver bullet; each solution trades off consistency, availability, performance, and complexity. Understanding these trade‑offs lets engineers pick the most suitable pattern for their distributed transaction needs.