# CAP theorem

> During a network partition, choose between answering and being linearizable.

Concept · Consistency & coordination · https://levelcode.org/concepts/cap-theorem

The CAP theorem is usually quoted as "consistency, availability, partition tolerance: pick two". The precise statement is narrower, and more useful:

> In a system that replicates data, when a **network partition** separates some nodes from others, the system must choose between **consistency** (every read sees the latest write, i.e. linearizability) and **availability** (every request to a non-failed node gets a non-error response).

## Partitions aren't optional

Switches fail, cables are cut, cloud zones lose connectivity, and long garbage-collection pauses look like partitions to everyone else. A distributed system can't promise partitions won't happen, so "CA" isn't a real option. The meaningful question is **what the system does during a partition**.

## CP and AP

- **CP:** nodes that can't confirm they have the latest data refuse requests — typically the minority side of the partition. etcd, ZooKeeper, Consul and databases built on Raft or Paxos behave this way. Correct, but parts of the system return errors until the partition heals.
- **AP:** every node keeps answering, possibly with stale data, and conflicting writes are reconciled afterwards. Cassandra and DynamoDB at default settings, DNS, and most caches behave this way.

## What CAP doesn't say

- **It's only about partitions.** It says nothing about latency in normal operation — that's what [PACELC](https://levelcode.org/concepts/pacelc) adds.
- **Its definitions are strict.** "Consistency" means linearizability only; "availability" means every non-failed node answers. Many real systems are neither fully CP nor fully AP, and many let you choose per request (Cassandra consistency levels, DynamoDB's `ConsistentRead`).
- **It's not a design method.** Choosing "AP" for a whole system is too coarse; choose per operation ([consistency models](https://levelcode.org/concepts/consistency-models)).

## Example

Two users try to claim the username `ana` on opposite sides of a partition. A CP system lets at most one side succeed (the other gets an error). An AP system lets both succeed and must resolve the duplicate later — unacceptable for usernames, fine for "likes".