Ensuring Distributed Consistency: From Local Transactions to Two‑Phase Commit

Introduction

In internet systems the ideal is to satisfy consistency, availability and partition tolerance simultaneously, but according to the CAP theorem and BASE theory this is impossible. In finance, consistency is paramount and must always be met. This article focuses on consistency solutions, namely strong consistency and eventual consistency.

Database Local Transaction

Database transactions provide strong consistency and are the simplest way to guarantee it, as the database ensures consistency without business‑layer involvement. A typical use case is refunding a purchase with cashback: both the original payment and the cashback must be refunded together, which can be achieved with a single local database transaction.

Two‑Phase Commit (2PC)

For distributed systems, distributed transactions are required, and the two‑phase commit protocol (2PC) is a common solution. Baidu’s NesioDB, a distributed database used in Baidu Wallet, implements 2PC to provide ACID guarantees similar to a single‑node database.

Phase 1 – Prepare

DTM sends a prepare message to each resource manager (RM). Each RM creates a local transaction, writes redo/undo logs, but does not commit.

Phase 2 – Commit/Rollback

If any RM reports failure or times out, DTM sends a rollback message; otherwise it sends a commit message. RMs then commit or roll back and release locks.

The same 2PC mechanism can be used to implement TCC (Try‑Confirm‑Cancel), a flexible transaction pattern that separates business and accounting services.

Rollback Mechanism

When coordinating multiple atomic services, a failure in any service can be handled by a rollback mechanism to maintain consistency. In a joint‑loan project, two atomic operations—fund collection and fund‑to‑card—must either both succeed or both fail, ensuring no money remains in an intermediate account.

Local Message Table

The local message table pattern, inspired by eBay and popularized by Alipay, splits a distributed transaction into a series of local transactions using a relational database table. Core business writes to a transaction table, while non‑core services write to a user‑oriented query table. Consistency between the two is achieved by publishing messages to a message queue and, if necessary, replaying missed messages.

Compensation Mechanism

Compensation is widely used in distributed systems, especially in wallet applications such as core checkout and payment‑to‑card. If a bank debit succeeds but the system crashes, a background “compensation” process resumes the interrupted workflow, ensuring eventual consistency.

Conclusion

The article presents several concrete projects from a core system and explains how each ensures consistency in distributed environments. No single solution fits all scenarios; practitioners must choose the appropriate approach based on business requirements.

Source: 36 Big Data