Understanding Distributed Consistency: CAP, BASE, and Consistency Models

Background of Distributed Consistency

With the emergence of distributed transactions, the traditional single‑node ACID model can no longer meet the demands of high‑traffic, high‑concurrency internet systems.

If we require strict consistency, we often have to sacrifice system availability, and vice versa. Building a distributed system that balances both availability and consistency is a challenging problem for many Java engineers.

Origin of Distributed Data Consistency

In storage systems, persisting data prevents loss during crashes, but it does not solve permanent single‑node failures. Therefore, data must be replicated across multiple machines to improve availability and reliability.

Once data is copied to several nodes, consistency problems arise.

Levels of Distributed Data Consistency

1. Strong Consistency : Every read operation returns the latest written value; writes must be immediately synchronized to all processes.

2. Weak Consistency : After a successful write, the system does not guarantee an immediate read of the new value, but aims to achieve consistency within a certain time window (e.g., seconds).

3. Eventual Consistency : A special case of weak consistency where the system guarantees that, after some time, all replicas will converge to the same state.

Consistency‑Related Theories

ACID (Atomicity, Consistency, Isolation, Durability) is the set of properties required for correct transaction execution in databases such as MySQL.

Atomicity : All operations in a transaction either complete fully or not at all.

Consistency : The data integrity constraints are preserved before and after the transaction. This includes two aspects: (a) database‑level constraints (e.g., unique keys, foreign keys) and (b) business‑level consistency (e.g., total balance remains unchanged in a bank transfer).

Isolation : The database prevents interference between concurrent transactions.

Durability : Once a transaction commits, its changes are permanent and will not be rolled back.

CAP Theory

The CAP theorem states that a distributed system can simultaneously guarantee at most two of the following three properties:

Consistency : All nodes see the same data at the same time (strong consistency) or eventually converge (weak consistency).

Availability : Every request receives a response, without guarantee that it contains the most recent data.

Partition Tolerance : The system continues to operate despite network partitions or node failures.

In practice, most systems prioritize Partition Tolerance, then make trade‑offs between Consistency and Availability.

BASE Theory

BASE extends CAP with three principles: Basically Available, Soft state, and Eventual Consistency.

Basically Available : The system remains operational even when some components fail, ensuring core functionality.

Soft State : The system may exist in intermediate states that do not affect overall availability; for example, asynchronous replication in MySQL.

Eventual Consistency : All replicas will converge to the same state after a finite period, a specific form of weak consistency.

BASE and ACID represent opposite design philosophies: ACID emphasizes strong consistency (typical of relational databases), while BASE focuses on high availability. Modern large‑scale, cross‑data‑center systems often combine both approaches to achieve a balanced trade‑off.

For further reading, see the linked articles on SSO implementation, load balancing principles, idempotency, large‑scale website architecture, Dubbo vs. Spring Cloud, and Redis cache challenges.