How Distributed Transactions Keep Money Transfers Consistent Without Locks

1 Local Transaction

Using the example of transferring 10,000 CNY from Alipay to YuEBao, the operation consists of two steps:

update A set amount = amount - 10000 where userId = 1;

update B set amount = amount + 10000 where userId = 1;

If both updates succeed, the balances remain consistent; a single database transaction can guarantee this.

When the tables reside on different database instances, local transactions no longer work, and distributed transactions become necessary.

2 Distributed Transaction – Two‑Phase Commit (2PC)

2PC involves a coordinator (TC) and multiple participants (Si). The protocol proceeds as follows:

The client sends a start request to the transaction coordinator.

TC writes a <prepare> record to its local log and sends <prepare> messages to all participants. Each participant records the request in its log before executing the local transaction.

Each Si executes its local transaction but does not commit; it replies yes if successful or no otherwise, also logging the response.

TC collects all replies. If every participant answered yes, TC sends commit to all Si; otherwise it sends abort. Participants then commit or roll back accordingly.

Logging on both TC and Si ensures recovery after failures.

Open‑source implementations such as Atomikos can provide 2PC for Java, but the protocol incurs high latency and long lock times, making it unsuitable for high‑throughput services.

3 Using Message Queues to Avoid Distributed Transactions

Instead of a heavyweight 2PC, a reliable message can act as a voucher. After Alipay deducts the amount, it creates a message instructing YuEBao to add the same amount. As long as the message is persisted reliably, eventual consistency is achieved.

3.1 Reliable Message Persistence

Two approaches:

3.1.1 Coupled Business and Message

The deduction transaction and the message insertion share the same database instance, ensuring atomicity.

3.1.2 Decoupled Business and Message

The workflow:

Before committing the deduction, Alipay requests the messaging service to record the message without sending it.

After the deduction transaction commits, Alipay confirms the send; the messaging service then delivers the message.

If the transaction rolls back, Alipay cancels the pending message.

An audit process periodically checks for messages that were not confirmed and updates their status.

This decoupling reduces coupling between business and messaging systems.

3.2 Preventing Duplicate Message Delivery

To avoid processing the same message twice, YuEBao maintains a message‑application status table. Before handling a message, it checks this table; if the message already exists, it is discarded; otherwise it processes the message and records it in the same transaction.

This technique was first proposed by eBay engineers in 2008 to solve duplicate delivery issues.