CAP Theorem

During a network partition a distributed system must choose between consistency and availability. CAP is a narrow guarantee, not a general ranking of databases.

distributed-systems

Definition

The CAP theorem states that a distributed data system cannot simultaneously guarantee consistency, availability, and partition tolerance. Since network partitions cannot be prevented in a real distributed system, the practical choice during a partition is between consistency (rejecting some requests to avoid divergent results) and availability (serving requests that may return stale data). Outside a partition, a system can often provide both, which is why CAP alone is a poor product comparison.

Context and scope

CAP helps reason about behavior during network failures, not about normal operation. It is often paired with PACELC, which also considers latency versus consistency when there is no partition. Systems may choose per operation: a payment may require consistency, while a feed may prefer availability.

Common misconceptions

CAP means you can pick any two permanently — partition tolerance is not optional in a distributed system
A CP system is always consistent and an AP system is always available — the trade-off applies during a partition, not at all times
CAP ranks databases — it describes a failure-mode trade-off, not overall quality or latency

Anti-patterns

Choosing a database solely by a CAP label without testing partition behavior
Assuming an AP system can enforce a global uniqueness constraint during a partition
Treating eventual consistency as a free property without conflict handling

Related concepts

Related examples

Authoritative source

https://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed/

The three properties

Consistency (C) — every read sees the most recent write or an error, in the linearizable sense.
Availability (A) — every request to a non-failing node receives a non-error response, without a guarantee that it contains the latest write.
Partition tolerance (P) — the system continues to operate despite dropped or delayed messages between nodes.

In a network partition, a node cannot both guarantee the latest value and answer every request. It must reject some requests to preserve consistency, or answer with potentially stale data to remain available.

What engineers actually choose

Partition occurs
├── reject writes/reads that cannot be consistent -> CP behavior
└── serve possibly stale data                   -> AP behavior

A payment ledger may choose CP for the debit operation. A product feed may choose AP and reconcile later. The choice can be per endpoint, not per database.

When to use this lens

Use CAP when designing failure behavior: what should the system do when replicas cannot communicate? Compared to PACELC, CAP ignores the latency-versus-consistency trade-off during normal operation; PACELC extends the analysis with the else branch. Compared to ACID, CAP is about distributed replication during partitions, not transaction guarantees on a single node.

Pitfalls

A CAP label does not tell you whether a system supports read-your-writes, how long convergence takes, or what happens to conflicting writes. Test partition behavior directly or read the vendor’s consistency documentation. Do not use CAP to claim one database is universally better than another.