Skip to content
System design course
Ch.2 · The building blocks·concept ·7 min read

The CAP theorem

When the network splits, you must choose consistency or availability — you can't keep both. The most-quoted and most-misused result in distributed systems.


The statement

In a distributed data store, you can guarantee at most two of:

  • Consistency (C) — every read sees the most recent write (one agreed-upon value everywhere).
  • Availability (A) — every request gets a (non-error) response, even if some nodes are down.
  • Partition tolerance (P) — the system keeps working despite the network dropping or delaying messages between nodes.

The part everyone gets wrong

Network partitions are not optional — in any real distributed system, messages between nodes will sometimes be lost or delayed. So P is mandatory. That collapses CAP into a single real choice, made only during a partition:

When a partition happens, do you stay Consistent (CP) or stay Available (AP)?

You’re not choosing two of three in general — you’re choosing C or A when the network breaks. The rest of the time you get both.

CP — choose consistency

During a partition, refuse operations that can’t be made safely consistent — return errors or block — rather than serve a possibly-stale or conflicting value.

  • Behavior: some requests fail until the partition heals.
  • Use when correctness beats uptime: bank balances, inventory, anything where a wrong answer is worse than no answer.
  • Examples: systems built on consensus (ZooKeeper, etcd); strongly-consistent modes of HBase, MongoDB.

AP — choose availability

During a partition, keep serving every request, accepting that different nodes may temporarily return different (stale) values; reconcile once the partition heals.

  • Behavior: always responds, but reads may be stale and writes may need conflict resolution.
  • Use when uptime beats freshness: shopping carts, social feeds, DNS, caches.
  • Examples: Cassandra, DynamoDB, Riak (tunable, AP-leaning).

How to use it in an interview

Don’t recite “two of three.” Instead pin the real decision to the data:

“The user’s feed is AP — better to show a slightly stale feed than an error. But their payment must be CP — I’d rather reject the charge during a partition than double-charge.”

Different parts of one system make different CAP choices. Saying that — and noting that CAP only bites during a partition — separates people who memorized it from people who understand it. PACELC (next) extends the idea to the normal, no-partition case.