Understanding Distributed System Consistency: CAP Theorem, ACID, Distributed Transactions, and 2PC/3PC Protocols

Modern internet applications increasingly rely on distributed systems and micro‑service architectures, where a single logical operation often involves multiple services and database instances. Achieving strong consistency in such environments is difficult, leading many systems to adopt eventual consistency based on the CAP theorem.

The CAP theorem states that a distributed system cannot simultaneously guarantee Consistency, Availability, and Partition Tolerance; most real‑world designs sacrifice strong consistency for higher availability, accepting eventual consistency instead.

ACID principles—Atomicity, Consistency, Isolation, Durability—describe the guarantees of traditional single‑node transactions. In distributed contexts, these guarantees must be re‑engineered, often by ensuring final consistency through idempotent operations and compensating actions.

Distributed Transaction Service (DTS) frameworks aim to preserve final consistency across large‑scale environments. Common techniques include using a local message table (originating from eBay) to split a global transaction into a series of local transactions, and employing message middleware (e.g., MQ) to propagate state changes.

Message‑oriented approaches face reliability challenges: successful database updates must be paired with successful message delivery. Solutions such as RocketMQ’s transactional messages introduce a three‑step process—prepare, local transaction execution, and commit/rollback confirmation—to synchronize message sending with local transaction outcomes.

The classic two‑phase commit (2PC) protocol coordinates participants via a coordinator that first gathers votes (prepare phase) and then issues commit or rollback commands (commit phase). While 2PC ensures strong consistency, it suffers from single‑point‑of‑failure, blocking, and potential data inconsistency under network partitions.

The three‑phase commit (3PC) extends 2PC by adding a pre‑commit (can_commit) stage and timeout handling, reducing blocking time and improving fault tolerance. However, 3PC still cannot fully eliminate inconsistency risks.

Overall, the article outlines the trade‑offs between consistency, availability, and partition tolerance, and reviews practical mechanisms—local message tables, transactional message queues, 2PC, and 3PC—to achieve reliable distributed transactions.