Distributed Transaction Consistency Solutions for E‑commerce Systems

In e‑commerce and similar large‑scale applications, systems are composed of many independent services, raising the problem of how to ensure data consistency during distributed calls.

Strong consistency : After an update, all subsequent reads return the latest value, but this requires sacrificing availability according to the CAP theorem.

Weak consistency : The system does not guarantee that reads will see the most recent write immediately.

Eventual consistency : A specific form of weak consistency where, in the absence of further updates, the system eventually returns the last written value; DNS is a classic example.

Practitioners often convert strong‑consistency requirements into eventual‑consistency ones and rely on idempotent operations to achieve final consistency. Six common solutions are discussed:

1. Avoid distributed transactions – Business integration : Merge services A, B, C into a single local service D, converting the problem to a local transaction. This eliminates distributed transactions but couples business logic and reduces clarity.

2. Classic eBay pattern (BASE) : Use an asynchronous message log (database or queue) to record operations, ensuring idempotency. The BASE principle (Basically Available, Soft state, Eventually consistent) replaces ACID, allowing partial failures without sacrificing overall availability. A local transaction records updates in a table updates_applied and a message queue; a second phase reads the queue, checks updates_applied, applies missing updates, and finally removes the message.

3. Qunar’s distributed‑transaction scheme : Split a monolithic application into independent subsystems (order, inventory, etc.). Use asynchronous messages with idempotent consumers or a dedicated transaction‑record table to coordinate retries and compensations when a service fails.

4. Mogujie’s order‑creation consistency : Create an invisible order first, then synchronously call coupon‑lock and inventory‑deduction services. On failure or timeout, send a cancellation message to MQ; the downstream services roll back if necessary, achieving near‑real‑time eventual consistency.

5. Alipay/Ant Financial Distributed Transaction Service (DTS) : A framework built on the BASE idea that provides eventual consistency across heterogeneous services (MySQL, Oracle, KV stores, HBase). It separates client (xts‑client) and server (xts‑server), offers a simple two‑phase‑like protocol, and abstracts away underlying transaction implementations.

6. Nongxin’s consistency approach : For payment and points systems, use synchronous calls with local transactions and explicit rollback logic; for user‑info changes, employ asynchronous MQ notifications with at‑least‑once delivery and idempotent processing.

All these methods share the core principle of breaking a global transaction into multiple local transactions and using retries, compensations, or message‑driven workflows to achieve final consistency without the heavy cost of traditional two‑phase commit.

References include the original eBay BASE paper and Alipay’s DTS documentation.