The Three Properties
In 2000, computer scientist Eric Brewer formulated the CAP Theorem, which was later formally proven by Gilbert and Lynch. It states that a distributed data store can only simultaneously guarantee two out of the following three properties:
- Consistency (C): Every read receives the most recent write or an error. Every node in the cluster sees the same data at the same time. This is also called linearizability — operations appear to happen instantaneously and in a globally agreed-upon order.
- Availability (A): Every request receives a non-error response, without the guarantee that it contains the most recent write. The system always answers, even if the data is slightly stale.
- Partition Tolerance (P): The system continues to operate despite messages being dropped or delayed by the network between nodes. A network partition is when one group of nodes cannot communicate with another group.
The Hard Truth: P Is Not Optional
Here is the crucial insight that most explanations gloss over: In any real distributed system, network partitions are not hypothetical — they are inevitable. Network cables get cut, switches fail, cloud availability zones lose connectivity, and firewalls misconfigure. You must design your system to tolerate partitions, or you are not building a distributed system at all — you are building a single-node system with extra steps.
Therefore, the CAP theorem is really saying: When a network partition occurs, you must choose between Consistency and Availability.
- CP System: When nodes cannot communicate, the system stops accepting writes (or returns errors) rather than risk serving inconsistent data. It is better to be temporarily unavailable than to have wrong data. Examples: traditional RDBMS clusters, Apache ZooKeeper, etcd, HBase.
- AP System: When nodes cannot communicate, the system keeps accepting reads and writes on both sides of the partition. The two sides diverge and reconcile later when the network heals. Examples: Apache Cassandra, Amazon DynamoDB, CouchDB.
Classifying Real Systems
| System | CAP Classification | Rationale |
|---|---|---|
| PostgreSQL (single node) | Not applicable | Not distributed |
| PostgreSQL + synchronous replication | CP | Writes block until replica confirms |
| Cassandra | AP | Accepts writes even during partition |
| etcd / ZooKeeper | CP | Uses Raft/Paxos consensus; refuses writes without quorum |
| DynamoDB (default) | AP | Eventually consistent by default |
| DynamoDB (strong reads) | CP | Trades latency for consistency |
Interviewers frequently ask: "Is your database CP or AP?" The trap is treating this as a permanent label. A sophisticated answer acknowledges that many modern databases let you tune this per-operation (e.g., DynamoDB's ConsistentRead flag, Cassandra's per-query consistency levels). The CAP classification describes the system's default behavior during a partition, not an immutable identity.