Lesson 7 of 17
16. Consistency and CAP

16.6 What does the CAP theorem actually say?

3 min read+10 XP

At the bank: While the line is cut, counter 2 can't both (a) always give Asha an answer and (b) always give her the right balance. It has to give up one of them until the line is fixed.

In the system: The CAP theorem was proposed by Eric Brewer (2000) and proved by Seth Gilbert and Nancy Lynch (2002). Stated carefully:

In a distributed system where the network can lose messages between nodes (partitions), you cannot guarantee both consistency (every read returns the most recent write, i.e. linearizability) and availability (every request to a working node gets a non-error response) at the same time.

So during a partition, each part of the system must choose:

  • Consistency (CP): refuse or delay some requests (errors, timeouts) rather than risk a stale or conflicting answer.
  • Availability (AP): answer every request from local data, accepting that answers may be stale and copies may diverge, to be reconciled later.

a partition between Mumbai and Frankfurt: CP refuses on one side, AP answers from a stale copy.

Figure: not "pick 2 of 3". Partitions happen anyway; CAP is the choice you make while one is happening.

Why "pick 2 of 3" is misleading:

  • P isn't optional. You can't choose to have no partitions. "CA" only describes a single machine, or a system that simply breaks during a partition.
  • The choice applies only during a partition. When the network is healthy, a system can be both consistent and available.
  • It's not all-or-nothing. The same system can choose differently for different data or operations, and the "C" and "A" in the proof are very specific definitions, stricter than everyday use. Brewer himself wrote about this nuance in 2012 ("CAP Twelve Years Later").

Memory code: "When the line is cut, refuse or risk: you can't promise both right and always."