Mastering Final Consistency: Strategies for Distributed Transactions

Current application systems, whether enterprise‑level or internet‑based, must confront the challenge of final data consistency. As distributed architectures become prevalent, achieving consistency grows harder and cannot be solved by a single middleware or framework; solutions must be tailored to business scenarios.

Basic Theory

The main theoretical foundations include ACID transaction properties, the CAP theorem for distributed systems, and BASE principles.

1. ACID Properties

Atomicity, Consistency, Isolation, Durability—core to traditional database transactions.

2. CAP Theorem

C (Consistency) : In classic databases, consistency is guaranteed by transactions; in distributed environments it refers to whether multiple nodes hold the same data.

A (Availability) : The service remains reachable and can return a result within a reasonable time.

P (Partition Tolerance) : The system continues to operate despite network partitions, appearing as a single coherent whole.

3. BASE Principles

BA : Basic Availability.

S : Soft state.

E : Eventual consistency.

Common Practices for Achieving Final Consistency

1. Single‑Database Transaction

When an application uses a single database, strong consistency can be ensured via the database's transaction mechanism, typically managed through Spring's transaction templates or declarative transactions.

2. Multi‑Database Transaction

For multiple databases, a two‑phase commit protocol can be employed, e.g., Spring 3.0 + Atomikos + JTA.

3. Transactional Message Queue

Business logic sends a message after successful processing; the message is committed only when the business operation succeeds, and the queue delivers it for further handling. This fits scenarios where the first phase succeeds and the second must also succeed.

4. Message Queue + Compensation Tasks

Instead of relying on the queue’s retry mechanism, a separate compensation task table records failures and retries them later, providing clearer visibility of pending issues.

5. Asynchronous Callback Mechanism

Service A calls Service B; after B returns success, B later callbacks A to confirm completion, similar to a TCP three‑way handshake.

6. Double‑Check Confirmation

A periodically re‑invokes B (seconds later or daily) to verify that the previous operation succeeded, adding an extra safety net.

Drawbacks of Distributed Transactions

1. Two‑Phase Commit Limitations

Involves multiple network round‑trips; long communication times extend transaction duration, holding locks longer and causing performance bottlenecks under high concurrency.

2. Message Queue Challenges

High‑throughput systems often replace distributed transactions with reliable message queues. To guarantee consistency, messages must be persisted together with business data.

Example (Alipay & Yu‑e‑bao):

When Alipay deducts funds, it records the message and business data in the same database, then sends the message to Yu‑e‑bao. After Yu‑e‑bao processes it and returns success, Alipay removes the message record, completing the transaction.

Begin Transaction
  update A set amount = amount-1000 where uid=100;
  insert into message(uid, amount, status) values (1, 1000, 1);
Commit;

Traditional approach: "I finish, then I send you a message." Improved approach with transactional messaging: "I first send you a message, complete my work, then confirm the completion," providing stronger consistency guarantees.