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

After receiving a salary, the author tried a cross‑bank transfer using a mobile app, encountered a "recipient name mismatch" failure, and observed the app automatically reversing the deducted amount, prompting a discussion about transaction safety.

The article then reviews local (database) transactions, emphasizing the ACID properties—especially consistency—and illustrates how atomicity and isolation prevent data anomalies in concurrent operations.

Next, it introduces the CAP theorem (Consistency, Availability, Partition tolerance) and explains why a distributed system cannot simultaneously satisfy all three, using a real‑world example of read‑write separation causing temporary data inconsistency.

Moving to distributed transactions, the author describes a naïve synchronous design for inter‑bank transfers and enumerates its drawbacks: thread blocking, traffic spikes, and data inconsistency when failures occur at various steps.

To address these issues, a message‑queue‑based asynchronous design is proposed: the debit operation is performed locally, the transfer request is written to a queue, a background worker processes the request, and the receiving bank replies with the result.

Although the queue solves some problems, it introduces new challenges such as queue availability, latency, and potential duplicate processing, which still threaten data consistency.

The solution adds a transfer‑log (transaction‑log) table on the sending side, persisted within a local transaction together with the debit operation. A background thread periodically scans pending log entries and re‑queues them, guaranteeing that no request is lost.

On the receiving side, a similar log table ensures idempotent processing: before handling a transfer, the system checks whether the log entry already exists, preventing duplicate credits.

Finally, the article stresses that the best approach is to avoid distributed transactions when possible, but if they are required, combining local transactions, reliable logging, asynchronous messaging, and idempotent handlers can maintain consistency across services.

(End)