Understanding CAP Theory and BASE: Data Consistency in Distributed Systems

1. CAP Theory: Data Consistency in Distributed Systems

1.1 Origin and Core Definition

The CAP theorem, proposed by Eric Brewer in 2000, states that a distributed system facing a network partition can satisfy at most two of the following three properties:

Consistency : all nodes see the same data at the same time (e.g., strong‑consistent transactions in MySQL).

Availability : every request receives a non‑error response (e.g., Eureka’s self‑protection mechanism).

Partition Tolerance : the system continues to operate despite communication failures between some nodes (a mandatory property of all distributed systems).

Classic Combination Interpretations

CA : suitable for single‑node or non‑distributed scenarios such as traditional relational databases.

CP : sacrifices availability to guarantee consistency (e.g., Zookeeper, etcd).

AP : sacrifices consistency to ensure availability (e.g., Eureka, Cassandra).

1.2 Technology Choices and Typical Components

Combination

Typical Components

Applicable Scenarios

Implementation Mechanism

CP

Zookeeper, etcd

Distributed locks, configuration centers

ZAB protocol / Raft protocol

AP

Eureka, Cassandra

Service discovery, high‑throughput writes

Eventual consistency / Quorum mechanisms

CA

MySQL master‑slave sync

Core financial transaction systems

Two‑phase commit (2PC)

Case Analysis

Zookeeper (CP) : uses the ZAB protocol for atomic broadcast; service may pause during leader election.

Eureka (AP) : allows temporary inconsistency of registration data and ensures service availability via heartbeat mechanisms.

Nacos (Hybrid) : can switch between CP and AP modes; configuration writes are strongly consistent while service discovery is weakly consistent.

2. BASE Theory: Engineering Extension of CAP

2.1 Core Ideas and Definitions

Basically Available : core functions remain usable under degradation (e.g., traffic‑limiting during e‑commerce spikes).

Soft State : intermediate states are allowed (e.g., an order in “payment pending” status).

Eventually Consistent : data will converge to a consistent state over time (e.g., daily reconciliation in payment systems).

2.2 Implementation Schemes and Typical Technologies

Scenario

Technical Solution

Key Characteristics

Asynchronous Replication

Kafka message queue

Producer acknowledgment + consumer retry

Compensating Transactions

Seata TCC mode

Try‑Confirm‑Cancel three‑phase control

Event Sourcing

Apache Pulsar

Reconstruct state from event logs

Version Control

DynamoDB conditional updates

Vector clocks resolve conflicts

Practical Points

Local Message Table : RocketMQ transactional messages use half‑message pre‑commit to ensure reliability.

Saga Pattern : splits long transactions into multiple sub‑transactions; on failure, compensating actions are executed.

Idempotent Design : unique IDs or version numbers prevent duplicate operations.