Understanding the CAP Theorem: Consistency, Availability, and Partition Tolerance

This article is a translation; author: James Bryden, original source: http://nosql-guide.com/cap-theorem-what-does-it-mean-to-you/

CAP Theory – Yes, No, or Maybe

If you have never encountered the CAP theorem, think of it this way: a distributed computer system cannot simultaneously satisfy the following three guarantees:

Consistency. All parts of the system see the same data at the same time.

Availability. Every request to the system receives a response, whether positive or negative.

Partition Tolerance. The system continues to operate despite message loss or partial failures.

These three properties form the acronym CAP, which gives the theory its name. Eric Brewer first introduced the CAP theorem in 2000, suggesting that system design must choose two of the three properties (CA, AP, or CP).

Using the CAP theorem to classify database technologies

Based on the combination of CAP properties, we can position traditional relational database management systems (RDBMS) and newer NoSQL data stores.

CA (Consistency + Availability): Relational Database Management Systems (RDBMS)

CP (Consistency + Partition Tolerance): MongoDB document store and Redis key‑value store

AP (Availability + Partition Tolerance): CouchDB document store and Riak KV store

A quick comparison of MongoDB and CouchDB replication shows their positioning: MongoDB provides a primary‑secondary replication model to improve consistency, while CouchDB offers multi‑master replication designed for higher availability and faster response.

ACID for relational databases

In the CA category, transactions exhibit ACID properties—Atomicity, Consistency, Isolation, and Durability. In other words, a transaction either fully succeeds or fully fails, moving the system from one valid state to another, and concurrent or sequential execution yields the same final result.

BASE for cloud‑scale systems

Conversely, in more elastic, cloud‑oriented environments that align with AP, ACID may not be appropriate. Brewer and his students introduced the BASE acronym—Basically Available, Soft state, Eventual consistency—to describe this paradigm, where using stale data or probabilistic estimates is acceptable.

CAP sequence

About twelve years after Brewer introduced the CAP theorem, he noted that additional description was needed. If partition tolerance is a goal, it does not necessarily force a strict split between consistency and availability; choices can be made within subsystems based on specific operations or data. The three properties are continuous rather than discrete, and ACID and BASE represent opposite ends of a spectrum rather than mutually exclusive states.

Design and operational choices

As applications scale, the impact of the CAP theorem becomes more pronounced. When transactions are infrequent, a distributed database can restore consistency with low latency without noticeable performance impact. Although strict CAP cannot be achieved in a distributed system, wise design can limit negative effects, ensure critical transactions, and optimize user experience elsewhere.