Ensuring Data Consistency: Local Transactions, Distributed Two‑Phase Commit, and Message‑Queue Solutions

When a user transfers 10,000 CNY from Alipay to Yu’ebao, the system must guarantee that the debit in the Alipay account and the credit in the Yu’ebao account are both applied; otherwise the data becomes inconsistent.

This situation appears in many domains, such as e‑commerce order processing or advertising click billing, where an update to one table must be reflected in another.

In technical terms, the problem is to ensure that after one table is updated, the dependent table is also updated successfully.

1. Local Transaction – If both the Alipay account table update A set amount=amount-10000 where userId=1; and the Yu’ebao account table update B set amount=amount+10000 where userId=1; reside in the same database instance, a single database transaction can guarantee atomicity.

When the tables are distributed across different physical nodes, a local transaction no longer works, and a distributed transaction is required.

2. Distributed Transaction – Two‑Phase Commit (2PC) – A coordinator (TC) and multiple participants (Si) exchange <prepare>, <yes> / <no>, and <commit> / <abort> messages while persisting each step to a local log for crash recovery. If all participants reply yes, the coordinator sends commit; otherwise it sends abort. Open‑source libraries such as Atomikos can implement 2PC in Java, but the protocol incurs high latency and long lock times, making it unsuitable for high‑concurrency services.

3. Using a Message Queue to Avoid Distributed Transactions – By treating the debit operation as a reliable message (a “voucher”), the system can achieve eventual consistency without a heavyweight transaction. The article draws an analogy to a restaurant receipt that separates payment from food pickup.

3.1 Reliable Message Persistence – Two approaches are described:

• Coupled method: the business transaction and the message are stored in the same database table (e.g., a message table). After the transaction commits, the message is pushed to a real‑time messaging service, which notifies the receiving system and awaits an acknowledgment before deleting the message.

• Decoupled method: before committing the business transaction, the service requests the messaging system to record the message without sending it. After the business transaction succeeds, it confirms the send; if the transaction fails, it cancels the send. A periodic status‑check component reconciles any uncertain messages.

The decoupled approach reduces coupling but requires two network calls and a status‑reconciliation mechanism.

3.2 Solving Duplicate Message Delivery – To prevent a message from being processed twice (which would double the credit), a message_apply table records the consumption status of each message. Before processing, the consumer checks this table; if the message already exists, it is discarded. This deduplication technique was pioneered by eBay in 2008.

Overall, the article demonstrates that while 2PC provides strong consistency, its performance drawbacks motivate the use of reliable messaging patterns with proper logging and deduplication to achieve eventual consistency in large‑scale backend systems.