Distributed Transaction and Data Consistency Solutions for E‑commerce Systems

In large‑scale e‑commerce systems, multiple independent services must cooperate while preserving data consistency, prompting a discussion of strong, weak, and eventual consistency models and their trade‑offs under the CAP theorem.

Strong consistency guarantees that every read sees the latest write but requires sacrificing availability; weak consistency offers no such guarantee; eventual consistency ensures that, absent further updates, all replicas will converge to the same value.

To achieve high availability without full strong consistency, the article outlines six practical approaches:

1. Business integration (avoid distributed transactions) – consolidate remote services A, B, C into a single local service D, converting the problem to a local transaction, though at the cost of tighter coupling and reduced modularity.

2. Classic eBay (BASE) pattern – use asynchronous message logs with idempotent processing, record applied updates in an updates_applied table, and rely on retries to achieve eventual consistency; this mirrors the BASE principle (Basically Available, Soft state, Eventually consistent).

3. Qunar’s distributed‑transaction solution – split a monolith into micro‑services, then transform distributed transactions into a series of local transactions coordinated via asynchronous messaging and compensating actions, handling failures through retries or rollbacks.

4. Mogujie transaction creation – create an invisible order first, then invoke coupon‑locking and inventory‑deduction services; on failure, send a cancellation message to MQ with retry logic, ensuring eventual consistency while keeping the critical path fast.

5. Alipay/DTS (Distributed Transaction Service) – a Java‑based framework that implements a BASE‑inspired two‑phase‑commit‑like protocol, providing eventual consistency across heterogeneous services (MySQL, Oracle, KV stores, HBase) without tying the system to a specific RPC or transaction engine.

6. Nongxin data‑consistency scheme – combine synchronous calls for low‑impact operations (e.g., points addition) with asynchronous MQ notifications for high‑impact actions, using idempotent consumers and retry mechanisms to maintain consistency.

All solutions share the core idea of breaking a global transaction into multiple local transactions and using reliable messaging, idempotency, and retry/compensation to achieve eventual consistency without the complexity of heavyweight two‑phase commit systems.