Understanding Distributed Transactions: From Local ACID to CAP Theory and Message‑Queue Solutions

After a cross‑bank transfer failed due to a mismatched account name, the author reflected on why money was deducted from his account but later returned, prompting a deeper look into the notion of "transactions" in software systems.

Local Transaction

Local transactions, also known as database transactions, obey the ACID properties—Atomicity, Consistency, Isolation, and Durability. Consistency is highlighted as the most fundamental, with the other three ensuring it.

In a classic example, account A transfers 100 CNY to account B within the same database. If the debit succeeds but the credit fails, data becomes inconsistent; therefore both operations must succeed or both roll back, illustrating atomicity and the need for redo/undo logging.

When multiple transactions run concurrently, isolation is required to prevent anomalies such as lost updates. Databases provide various isolation levels, locks, and optimistic/pessimistic strategies to preserve consistency under concurrency.

Distributed Theory

The author recalls a real‑world scenario where read‑write splitting caused stale reads, leading to an introduction of the CAP theorem (Consistency, Availability, Partition tolerance). In a distributed system, only two of these three guarantees can be satisfied simultaneously.

Consistency here means strong (linear) consistency—reads after a write must see the latest value. Availability requires every non‑failing node to respond promptly. Partition tolerance ensures the system continues operating despite network partitions.

Because data is spread across network partitions, guaranteeing both consistency and availability is impossible; trade‑offs must be made, often sacrificing availability to maintain consistency.

Distributed Transaction

Distributed transactions aim to preserve ACID guarantees across multiple services or databases. Solutions include XA, TCC, and message‑queue‑based approaches; the article focuses on the latter.

A naïve synchronous design involves four steps: (1) debit A’s account, (2) call B’s transfer API, (3) credit B’s account, (4) return the result. This design suffers from thread blocking, traffic spikes, and inconsistency if failures occur at any step.

Introducing a message queue solves the first two problems by decoupling the call: (1) debit A, (2) enqueue a request to B, (3) return immediately, (4) a background worker processes the queue, (5) B credits the account, (6) B notifies A of the result. However, new issues arise, such as message loss and duplicate processing.

To handle message loss, a transaction‑log table is added with fields like tId, accountNo, targetBankNo, amount, status, and lastUpdateTime. The debit and log insertion are wrapped in a local transaction, guaranteeing atomicity. If the system crashes before enqueuing the message, a compensation thread later reads pending logs and re‑queues them.

To ensure idempotency on B’s side, B also maintains a log table. Upon receiving a request, B checks the log for the unique transaction ID; if already processed, it skips the operation and returns the previous result.

Overall, the core idea is that A uses a local transaction plus a background retry mechanism to avoid lost messages, while B uses a local transaction to guarantee idempotent processing. The article concludes that the best strategy is to avoid distributed transactions whenever possible.

For further reading, the author provides links to related articles on Redis, HAProxy, and other technical topics.