CAP Theorem

During a partition, a distributed system must choose consistency or availability for the affected operations

The actual choicepartition + conflicting op -> C or A
Not "pick 2 of 3"a temporary, partition-scoped trade-off
CP exampleetcd/Raft — rejects writes without quorum
AP exampleDynamo-style — accepts writes, reconciles later

1.What CAP actually says

The CAP theorem describes one specific moment: a network partition has split a distributed data system into two (or more) groups of nodes that cannot talk to each other, and a request arrives at a node that would need to coordinate with the unreachable side to answer safely. At that exact moment, the system has only two choices for that request — answer it anyway using only local, possibly-stale data (favoring Availability), or refuse to answer until the partition heals and the nodes can agree (favoring Consistency). It cannot do both, because doing both would require talking to a node it cannot reach.

Key features

CAP applies specifically to a network partition — nodes that cannot reach each other but are each still running
The choice is between Consistency (every read sees the latest write, or an error) and Availability (every request gets a non-error response, though possibly with stale data)
Partition Tolerance is not really optional in a real distributed system — networks fail, so a system must have some defined behavior for that case
The trade-off applies per conflicting operation during the partition, not as one global setting for the whole system for all time
Formalized by Eric Brewer as a conjecture in 2000 and proven by Gilbert and Lynch in 2002 for the asynchronous network model

The two choices available during an actual partition

The two choices available during an actual partition
Choice	What the node does	Cost
Favor Consistency (C)	Refuses or delays the request until it can confirm the latest state	Reduced availability — some requests get errors or timeouts
Favor Availability (A)	Answers using local data, without confirming it against the unreachable side	Reduced consistency — the answer may be stale or later conflict with the other side

Split-brain: two writes, one key, a broken link

Client 1

Node A

Node B

Client 2

1network partitionA and B can no longer reach each other
2write cart:42 = {qty: 1}
3write cart:42 = {qty: 3}
4AP: both accepteddiverges — must reconcile once healed

Command

text

Partition detected -> request needs cross-partition data
  -> choose C: return error/timeout until reachable
  -> choose A: return local (possibly stale) answer

CAP is a statement about one moment: a network partition plus a conflicting operation. At that moment, favor Consistency (refuse/delay until certain) or Availability (answer locally, possibly stale) — not both, for that operation.

2.CAP is not "pick 2 of 3, permanently"

The popular shorthand "pick two of Consistency, Availability, Partition tolerance" is a common misreading. Partition tolerance is not something most real systems can opt out of — networks fail regardless of what a system "picks" — so it is not a peer choice alongside C and A. What CAP actually constrains is narrower: only while a partition is actually happening, and only for the specific operations that would need to coordinate across the split, does a system have to give up either consistency or availability. Outside of a partition, the same system is normally both consistent and available at once — there is no theorem forcing it to sacrifice one permanently.

Key features

Most distributed databases are both consistent and available during normal operation, when no partition is occurring
The trade-off in CAP is forced only during an active partition, and only for operations that need data from the unreachable side
"CP" and "AP" as labels describe a system's default behavior during a partition, not what it does the rest of the time
Partition tolerance is not realistically optional for a system with more than one node communicating over a real network — so treating it as a free third choice alongside C and A is misleading
Eric Brewer himself later clarified the "2 of 3" framing was oversimplified — see his 2012 "CAP Twelve Years Later" retrospective

The misreading vs. what CAP actually constrains

The misreading vs. what CAP actually constrains
Claim	Misreading	What CAP actually says
Scope	Applies to the system at all times	Applies only during an active partition
Which operations	Every operation is affected	Only operations needing cross-partition coordination
Partition tolerance	A third property you can trade away	Not realistically optional — networks do fail
Normal operation	System is permanently missing one property	System is typically both consistent and available

The CAP trade-off is temporary, not permanent

networksplitspartitionheals

Healthy

start

Partitioned

Healed

end

Command

text

No partition:  system is both consistent AND available
Partition, operation needs the other side:
  -> now, and only now, choose C or A for that operation

Partition tolerance is not a free third choice — real networks fail regardless. CAP forces a C-vs-A trade-off only during an actual partition, only for the operations that need the unreachable side; the rest of the time, most systems are both.

3.A real system's CAP choice: leader-based CP vs. multi-writer AP

Two concrete, well-known systems make opposite defaults for the same partition scenario. etcd (used for Kubernetes cluster state and distributed locks) uses the Raft consensus algorithm and requires a majority (quorum) of nodes to agree before a write is accepted — during a partition, the minority side simply cannot get writes through, so it returns errors instead of stale answers: that is a CP choice. Dynamo-style stores built for availability (the design popularized by Amazon's original Dynamo paper, and reflected in systems like Cassandra) instead accept writes on any reachable replica during a partition and reconcile conflicting versions after the partition heals: that is an AP choice. Neither is "better" in the abstract — they produce different concrete failures for the exact same network event.

Key features

etcd requires a Raft quorum (a majority of nodes) to commit a write — a minority partition cannot reach quorum, so it rejects writes rather than serve possibly-stale ones: CP behavior
Dynamo-style AP stores use techniques like sloppy quorums and vector clocks to accept writes on multiple replicas during a partition, then reconcile divergent versions once it heals
The CP consequence: reduced availability during the partition — the minority side returns errors/timeouts for affected operations, but no reader ever sees two conflicting values
The AP consequence: reduced consistency during the partition — every replica stays writable, but the system (or the application) must resolve conflicting writes after the fact
The same underlying network event (a partition) produces a visible outage in a CP system and a visible data-conflict-to-resolve in an AP system — the trade-off shows up as a different kind of problem, not as one system "handling it better"

Two real systems, opposite defaults, same partition

Two real systems, opposite defaults, same partition
System	CAP default	Mechanism	Consequence during a partition
etcd (Raft consensus)	CP	Requires majority quorum to commit a write	Minority-side writes fail fast with an error; no conflicting data is ever visible
Dynamo-style store (e.g. Cassandra)	AP	Accepts writes on reachable replicas; reconciles later	All sides keep accepting writes; conflicting versions must be merged once reachable again

Same partition, opposite defaults

etcd (CP, Raft)

Requires majority quorum to commit
Minority side rejects writes with an error
No client ever sees conflicting data

Dynamo-style (AP)

Accepts writes on any reachable replica
All sides keep working, no errors
Conflicting versions reconciled after healing

Command

text

CP (etcd/Raft):   write -> needs majority ack -> no quorum -> error
AP (Dynamo-style): write -> accepted locally -> reconciled after heal

etcd (Raft, needs quorum) rejects writes on the minority side during a partition = CP, fails loud. Dynamo-style stores (Cassandra and similar) accept writes on every reachable side and reconcile later = AP, fails quiet (a conflict to resolve, not an error).

Spotted a mistake on this page? Tell us.

Read Sheet