The Three Properties
C — Consistency
Every read receives the most recent write, or an error. Every node in the distributed system sees the same data at the same time. If you write a value to node A and immediately read from node B, you get that same value.
Example: You transfer $1,000 from your savings account. If the system is consistent, checking your balance immediately from any region shows $1,000 less. If it is inconsistent, some nodes might still show the old balance.
A — Availability
Every request receives a response (not an error), though the response might not contain the latest data. The system is always up and responsive — no node refuses requests.
Example: Even if some database nodes are unreachable, the remaining nodes continue serving reads and writes without returning errors.
P — Partition Tolerance
The system continues to operate even when network partitions occur — when some nodes cannot communicate with others due to network failures.
Why P is mandatory: In any real distributed system spanning multiple machines or datacenters, network partitions are not hypothetical — they happen. Switches fail, cables are cut, datacenter links drop. A system that cannot tolerate partitions is not a distributed system — it is a single-node system.
The Impossible Triangle
When a network partition occurs, a distributed system must choose:
- CP choice: Stop accepting writes (or return errors) to maintain consistency. Nodes that cannot confirm the write with a majority refuse to serve requests. The system is consistent but unavailable during the partition.
- AP choice: Continue serving reads and writes from all available nodes, accepting that different nodes may have different (stale) data until the partition heals and they synchronise.
CP Systems — Consistency Over Availability
CP systems prioritise returning correct, consistent data. During a network partition, they refuse to serve requests (return errors or timeouts) rather than risk returning stale data.
- HBase: Uses HDFS, strict consistency, refuses writes if region server is unavailable
- Zookeeper: Coordination service — must be consistent for distributed locks and leader election
- etcd: Kubernetes uses etcd for cluster state — must be consistent or cluster misbehaves
- MongoDB (default): With majority write concern, refuses writes that cannot reach a majority of replica set nodes
AP Systems — Availability Over Consistency
AP systems prioritise always returning a response. During a partition, all nodes remain available and accept reads/writes — but different nodes may have different data until the partition heals.
- Cassandra: All nodes accept writes; eventual consistency with tunable consistency level (ONE, QUORUM, ALL)
- DynamoDB (default): Eventually consistent reads — may return slightly stale data for lower latency
- CouchDB/Couchbase: Multi-master replication — all nodes accept writes, conflicts resolved later
- DNS: Updates propagate gradually — you might get stale IP for hours (TTL-based eventual consistency)
Real Database CAP Classification
| Database | CAP Class | Consistency Model | Notes |
|---|---|---|---|
| PostgreSQL (single node) | CA | ACID, strong consistency | Not partition tolerant by design |
| MySQL (single node) | CA | ACID, strong consistency | Same as PostgreSQL |
| MongoDB | CP (default) | Tunable: majority or local | Can tune to AP with w:0 |
| Cassandra | AP | Eventual (tunable per-query) | QUORUM = stronger consistency |
| DynamoDB | AP (default) | Eventual or strong (extra cost) | Strong consistency opt-in |
| HBase | CP | Strong consistency | Built for consistent reads |
| Redis (single) | CA | Strong in memory | Redis Cluster is CP |
| etcd | CP | Raft consensus — linearizable | Used by Kubernetes |
| CouchDB | AP | Eventual, MVCC | Multi-master replication |
| Zookeeper | CP | Sequential consistency | Leader-based writes |
Beyond CAP — The PACELC Theorem
CAP only addresses behaviour during partitions. The PACELC theorem (Daniel Abadi, 2012) extends it: Partition → choose Availability or Consistency; Else (no partition) → choose Latency or Consistency.
Even without partitions, there is a trade-off: strong consistency requires synchronous replication (waiting for all nodes to confirm writes) = higher latency. Low latency requires asynchronous replication = potential inconsistency window.
| Database | Partition (CAP) | Normal (ELC) |
|---|---|---|
| DynamoDB | PA | EL (low latency, eventual) |
| Cassandra | PA | EL (low latency default) |
| MongoDB | PC | EC (consistency) |
| PostgreSQL | PC (in cluster) | EC (consistency) |
Practical Guidance
For financial data, inventory, and anything requiring correctness: choose CP (PostgreSQL, MongoDB with majority writes, HBase). For user-facing data where slight staleness is acceptable and global availability matters more than perfect consistency: choose AP (DynamoDB, Cassandra). Most applications actually need a mix — use CP for financial transactions and AP for activity feeds, recommendations, and counters.
CAP Is a Theoretical Model with Nuances
The original CAP theorem deals with binary choices under worst-case network partitions. Real systems offer tunable consistency — Cassandra lets you choose ONE/QUORUM/ALL per query. Modern databases (Spanner, CockroachDB) use clock synchronisation and consensus algorithms to provide strong consistency with wide availability, challenging the traditional CAP framing. CAP is a useful mental model, not a rigid constraint.
How We Research and Update This Guide
We test the underlying formula or workflow, compare outputs with reliable references, and revise examples whenever the page content changes.
- The workflow or formula is tested directly in the tool and compared against independent reference examples.
- Examples are kept practical so readers can verify the result without hidden assumptions.
- Pages are revised whenever the interface, calculation flow, or surrounding guidance materially changes.
Frequently Asked Questions — CAP Theorem
The CAP theorem (Brewer's theorem, 2000) states that a distributed data store can guarantee at most 2 of 3 properties: Consistency (every read returns the most recent write or an error), Availability (every request receives a response — no errors, though possibly stale), and Partition Tolerance (the system continues operating despite network partitions — message loss or delay between nodes). Since network partitions are inevitable in any real distributed system, the practical choice is always between Consistency and Availability during a partition.
A network partition is when communication between nodes in a distributed system fails — some nodes cannot reach others. This happens in production regularly: a network switch fails, a datacenter loses connectivity, a cloud provider has an outage. Partition tolerance (P) means the system continues to function even when some nodes cannot communicate. In practice, you cannot choose to avoid P — distributed systems must tolerate partitions. So the real CAP choice is: when a partition occurs, do you sacrifice Consistency (AP) or Availability (CP)?
CP systems (Consistency + Partition Tolerance): during a partition, the system refuses to serve requests rather than risk returning stale data. Clients get errors or timeouts. Examples: HBase, Zookeeper, etcd. AP systems (Availability + Partition Tolerance): during a partition, all nodes remain available but may return stale/inconsistent data. Nodes sync when the partition heals. Examples: Cassandra, CouchDB, DynamoDB (default). The choice depends on your use case: banking/inventory (must be consistent), social media/shopping cart (can be eventually consistent).
Eventual consistency is the model used by AP systems. When a write happens to one node, other nodes will eventually receive the update — but during the propagation window, different nodes may return different values. "Eventually" could mean milliseconds or seconds, depending on the system. Amazon's DynamoDB, Cassandra, and Couchbase use eventual consistency by default. Many AP systems let you tune consistency level per request (Cassandra: ONE, QUORUM, ALL) — trading latency for stronger guarantees.
Not quite. The PACELC theorem extends CAP: even when there is no partition (E), there is a trade-off between Latency (L) and Consistency (C). Systems optimising for low latency (replicate asynchronously) get inconsistency. Systems requiring strong consistency (synchronous replication, wait for all nodes) get higher latency. MySQL and PostgreSQL are traditionally CA systems in the CAP sense — they prioritise consistency and availability on a single node but are not designed for multi-datacenter partition tolerance by default.
CP systems (choose consistency over availability): HBase, Zookeeper, etcd, MongoDB (by default in its replica set mode with majority writes), Redis Cluster. AP systems (choose availability over consistency): Cassandra, DynamoDB (default), CouchDB, Riak, Couchbase. Traditional RDBMS (PostgreSQL, MySQL): CA in single-node; when distributed (multi-region), they typically choose CP (synchronous replication) or manually configured AP (async replication, read from replicas). Most modern databases allow tuning the consistency level per operation.