Master Distributed System Consistency: CAP, ACID, BASE & Transaction Protocols

CAP Theorem

The CAP theorem describes the trade‑offs among Consistency, Availability, and Partition tolerance in distributed systems. Understanding these principles guides the design of fault‑tolerant architectures.

Network connectivity: normal communication between service nodes.

When network partitions occur, communication may be delayed or interrupted, leading to partition tolerance challenges.

Partition tolerance: the system continues operating despite network partitions.

Consistency

Every read request should return the most recent write, regardless of which node is accessed.

In a distributed transaction, if a write (e.g., v=v1 ) is not yet replicated to all replicas, a subsequent read may return stale data, violating consistency. To maintain consistency, updates must be propagated to all replicas before reads are served.

Availability

Achieving high availability often requires sacrificing strict consistency.

Unavailability can arise from single‑node failures, dependent service failures, or delays during data synchronization, causing temporary service outages.

ACID Theory

Atomicity : a transaction is all‑or‑nothing.

Consistency : transaction boundaries preserve database integrity.

Isolation : concurrent transactions do not interfere with each other.

Durability : once committed, changes persist permanently.

Ensuring ACID properties in distributed environments requires transaction protocols that handle network and node failures.

2PC Transaction Protocol

Two‑phase commit consists of a voting phase and a commit phase. A coordinator orchestrates the transaction, and participants log undo/redo information.

Voting phase

Coordinator sends a prepare request ( v=v1 ) to participants, which record logs and respond.

Commit phase – success

If all participants agree, the coordinator issues a commit, and participants finalize the transaction.

Commit phase – failure

If any participant aborts or times out, the coordinator triggers an abort, rolling back changes using undo logs.

3PC Transaction Protocol

Three‑phase commit adds a pre‑commit step to avoid blocking. It reduces the chance of indefinite waits but still faces consistency issues if the coordinator fails during pre‑commit.

TCC Transaction Protocol

Try‑Confirm‑Cancel (TCC) separates resource reservation (Try), confirmation (Confirm), and rollback (Cancel). It relies on explicit resource locking and compensating actions to achieve distributed ACID guarantees.

BASE Theory

Basically Available : the system remains operational, though some features may be degraded.

Soft state : data may change over time during synchronization.

Eventual consistency : all replicas converge to the same state eventually.

Data Consistency Models

Linear (strong) consistency: all nodes see the same data at any time.

Sequential (weak) consistency: operations appear in the same order across nodes.

Eventual consistency: replicas become consistent over time.

Basic Availability Strategies

Traffic shaping: stagger requests, rate‑limit, or use queueing mechanisms.

Delayed responses: allow clients to wait during high load.

Graceful degradation: fallback responses when dependent services are unavailable.

Overload protection: limit traffic at load balancers or reject excess tasks.

Reference Documents

<code>## 有状态与无状态服务
https://nordicapis.com/defining-stateful-vs-stateless-web-services/

## CAP 定理
https://dzone.com/articles/understanding-the-cap-theorem
https://dzone.com/articles/quick-notes-what-cap-theorem
</code>

Further detailed analysis of consistency will be covered in the next article.