The CAP theorem, first described by Eric Brewer in 2000 and formally proved shortly after, states that a distributed data store can only guarantee two of three properties: Consistency, Availability, and Partition tolerance. It is one of the most-cited results in distributed systems — and one of the most misapplied. In 2026, understanding CAP means understanding what it actually constrains and what it leaves open.
What changed in 2026
- PACELC is the practical framing most teams use now. CAP only describes behavior during a network partition; PACELC extends it to cover the latency vs consistency tradeoff during normal operation — which is where most real decisions happen.
- Tunable consistency is the norm. DynamoDB, Cassandra, MongoDB, and CockroachDB all let you choose consistency level per request — strict quorum, eventual, session, or linearizable.
- Multi-region architectures made C vs A decisions unavoidable. Teams running active-active multi-region deployments encounter CAP tradeoffs regularly, not just theoretically.
- Distributed SQL (CockroachDB, Spanner, YugabyteDB) proved CP is practical at scale. Strong consistency across global nodes is no longer just a research project.
The three properties
Consistency (C) — Every read receives the most recent write or an error. Every node in the system sees the same data at the same time. This is linearizability in formal terms.
Availability (A) — Every request receives a non-error response (though it may be stale). The system remains operational even if some nodes are unreachable.
Partition tolerance (P) — The system continues operating despite network partitions (some nodes cannot communicate with others).
Why P is non-negotiable
Network partitions happen. Cables are cut, switches fail, cloud availability zones have outages. Any distributed system that claims to sacrifice Partition tolerance is really claiming to only run on a perfectly reliable network — which doesn't exist.
This makes CAP a choice between Consistency and Availability during a partition:
Network partition occurs
↓
Either: reject writes until partition heals (CP — consistent but unavailable)
Or: accept writes on both sides, merge later (AP — available but inconsistent)
CP vs AP in practice
| Category |
Examples |
Behavior during partition |
| CP |
PostgreSQL, CockroachDB, Zookeeper, etcd |
Refuses or errors writes to minority partitions |
| AP |
Cassandra, DynamoDB (default), CouchDB |
Accepts writes; resolves conflicts after partition heals |
| Tunable |
MongoDB, DynamoDB, Cassandra |
Configurable per operation |
# Cassandra — consistency level per query
SELECT * FROM orders WHERE id = 123 USING CONSISTENCY QUORUM; -- CP behavior
SELECT * FROM orders WHERE id = 123 USING CONSISTENCY ONE; -- AP behavior
PACELC: the more useful model
PACELC stands for: If Partition → Availability or Consistency; Else → Latency or Consistency.
Even without a partition, distributed systems trade latency for consistency:
- High consistency = all nodes must agree before responding → more round trips → higher latency.
- Low latency = respond immediately from the nearest node → may be stale.
| System |
Partition behavior |
Normal-operation behavior |
| DynamoDB (default) |
PA |
EL (low latency, eventual) |
| DynamoDB (strong reads) |
PA |
EC (consistent, higher latency) |
| CockroachDB |
PC |
EC (strong, slightly higher latency) |
| Cassandra (ONE) |
PA |
EL |
| Cassandra (QUORUM) |
PC |
EC |
How to pick
- Financial transactions, inventory, seat booking → CP. Data must be correct; brief unavailability is preferable to incorrect data.
- User sessions, caches, social feeds → AP/tunable. Stale data is acceptable; availability matters more.
- Configuration, leader election, distributed locks → CP always. Use etcd or Zookeeper; never use an AP store for coordination.
- Multi-region with low-latency reads → tunable consistency with strong writes and eventual reads.
Common mistakes
Conflating linearizability with serializability. Linearizability (CAP's C) is about single-object operations being ordered in real time. Serializability (ACID's I) is about multi-object transactions appearing atomic. A system can have one without the other.
Assuming eventual consistency "eventually" means fast. "Eventual" has no time bound. Cassandra replication lag is typically milliseconds, but under network stress it can be seconds or longer.
Using AP stores for counters without understanding convergence. CRDTs and last-write-wins strategies behave differently — pick the right conflict resolution for your data type.
Over-specifying consistency for every operation. Running all Cassandra queries at QUORUM when ONE is fine for non-critical reads wastes latency and throughput.
What to skip
- Building your own distributed consensus — use Raft (etcd, CockroachDB) or Paxos-based systems rather than implementing consensus from scratch.
- Treating CAP as a permanent choice — modern systems let you tune consistency per request; you rarely have to commit to one end of the spectrum.
- Ignoring PACELC — teams optimizing for partition behavior while ignoring latency-consistency tradeoffs miss the more frequent operational reality.
FAQ
Is Postgres CP or AP?
Single-node Postgres is not a distributed system in the CAP sense. In a Postgres primary-replica setup with synchronous replication, the system is effectively CP: the primary refuses commits if it cannot replicate to the synchronous standby.
Can a system be both consistent and available?
In the absence of partitions, yes — and most of the time there are no partitions. PACELC captures this: normal operation is about latency vs consistency, not availability.
What does "eventual consistency" actually mean?
If no new updates are made, all nodes will converge to the same value. It does not specify when. In practice, most AP systems converge in milliseconds to low seconds under normal conditions.
Does CockroachDB sacrifice availability for consistency?
CockroachDB is CP: it uses Raft consensus and will refuse writes to a partition minority. However, it uses multi-region replication so the partition threshold is very high in practice.
Where to go next