The three letters

CAP stands for Consistency, Availability, and Partition tolerance. Each word already has an everyday meaning that will mislead you slightly, so before anything else, here's what each one means specifically in this context — a distributed system, meaning data that's copied across more than one machine.

C — Consistency

In this context, consistency means every node in the system agrees on the current value. If you write a new value to the system and then immediately read it back — from any node — you get that new value, not an old one. There is one true answer, and every copy reflects it.

Node A: balance = $500
Node B: balance = $500
Node C: balance = $500

-> a client writes balance = $400 to Node A
-> consistency means A, B, and C ALL now say $400, before any client
   is allowed to read $500 again from any of them

What just happened: consistency here is entirely about agreement across copies of data, not about a single database enforcing rules like "balances can't go negative." That second meaning is a real thing too — it's the "C" in ACID — but it's a different concept that happens to share a letter. In CAP, consistency is purely: does everyone see the same, latest value, right now.

A — Availability

Availability means every request that reaches a working node gets a response — not an error, not a timeout, an actual answer. It says nothing about whether that answer is the newest value. It only promises that the system answers.

Client sends: GET balance

Available system's promise:
  -> you WILL get a response (even if it might be slightly stale)

NOT the promise:
  -> the response is guaranteed to be the very latest value

What just happened: availability is a promise about responsiveness, full stop. A system can be perfectly available and still hand you data that's a few seconds out of date. Those are two separate axes, and CAP is specifically about the tension between them — which is exactly why conflating "available" with "correct" is the fastest way to misread this theorem.

P — Partition tolerance

A partition is when the network between nodes breaks — a cable gets cut, a data center loses connectivity, a router drops packets — and some nodes can no longer talk to others, even though every individual node is still running fine. Partition tolerance means the system keeps operating in some form despite that split, rather than halting entirely.

Before the partition:
  [Node A] <---> [Node B] <---> [Node C]     (all connected, one system)

During a partition:
  [Node A] <---> [Node B]      X      [Node C]
                          (network split — C is cut off from A and B)

What just happened: Node C hasn't crashed. It's still running, still has data, still can answer requests from clients that can reach it. What it can't do is talk to A and B to confirm it has the latest value or to tell them about new writes. Partition tolerance is about what happens next — does the system keep working in this split state, or does it stop entirely until the network heals?

Consistency is about agreement. Availability is about responsiveness. Partition tolerance is about surviving a broken network instead of giving up.

Why partition tolerance isn't really optional

It's tempting to read CAP as "pick any two of three," as if you could choose not to have partition tolerance and get to keep both consistency and availability. In practice, that's not a real option for any system whose nodes talk over a network — and every distributed system does. Networks fail. Cables get cut, switches misbehave, cloud regions have outages. A system that isn't partition-tolerant isn't a system that has "chosen CA" — it's a system that stops working correctly the moment a partition happens, which is a matter of when, not if.

Not partition-tolerant  ->  breaks (in some way) the moment a real partition occurs
Partition-tolerant       ->  keeps running during a partition, but must choose:
                              stay consistent, or stay available. Not both.

What just happened: this reframes the whole theorem. It isn't really "pick two of three" as a free menu. Partition tolerance is a fact of life for any real distributed system — the actual decision, the one you get to make, is what to do during a partition: favor consistency, or favor availability. Phase 2 walks through exactly why you can't have both once the network is actually split.

← Overview | Phase 2: Why you can't have all three →