CAP Is Not “Pick Two of Three”, and It Describes the Rare Case

The CAP theorem is the most-repeated and most-mangled idea in distributed systems. The version everyone learns is “consistency, availability, partition tolerance: pick two.”

That is wrong in two separate ways, and the author of the theorem said so himself.

Wrong the First Way: You Do Not Choose P

Partition tolerance is not a feature you enable. A partition is two parts of your system being unable to talk to each other, and that happens because a cable failed, a switch rebooted, a security group changed, or a cloud provider had a bad afternoon.

You do not opt out of that. It happens to you.

So when someone describes a system as “CA”, choosing consistency and availability while forgoing partition tolerance, they are describing either a single machine, which is not a distributed system, or a distributed system that will fail in an undefined way the first time a network hiccups. There is no third reading. The only genuine question is what happens once a partition has occurred.

Wrong the Second Way: The Trade-off Is Not Permanent

This is the correction Eric Brewer published in 2012, and it is the one that changes how the theorem is useful. The choice between consistency and availability only applies while a partition is happening. When the network is healthy, a system can deliver all three.^[1]

Reread the popular framing with that in mind and it collapses. It is not a standing architectural allegiance. It is a decision about behaviour during an exceptional condition, and it can even be made differently for different operations inside the same system.

Brewer added a second correction in the same paper, which gets quoted even less: all three properties are continuous rather than binary. Availability is obviously continuous from 0 to 100 percent. Consistency has many distinct levels. Even partitions have nuances.^[1] Real systems sit somewhere on a surface, not at one of three corners of a triangle, and the triangle diagram is most of why people think otherwise.

What the Choice Actually Looks Like

A partition splits your database into two halves that cannot reach each other. A write arrives at one half. You have exactly two options and there is no clever third.

Stay consistent. Refuse the write, because you cannot confirm the other half agrees. The caller gets an error. Nothing incorrect is ever stored, and you have chosen consistency by sacrificing availability.

Stay available. Accept the write locally and reconcile later. The caller succeeds. For a period the two halves disagree, and somebody has to define what happens if both halves accepted conflicting writes to the same record.

Which is correct depends entirely on what the data is. A balance transfer should refuse: two halves independently approving withdrawals from one account is exactly the failure that must not happen. A like on a post should accept: a count briefly disagreeing across regions is not a problem worth an outage.

PACELC, Which Describes Your Actual Tuesday

Here is the part I wish had replaced CAP in the curriculum. Daniel Abadi proposed PACELC in 2010, and it reads as one sentence:^[2]

If there is a Partition (P), choose between Availability (A) and Consistency (C). Else (E), choose between Latency (L) and Consistency (C).

The first half is CAP. The second half is the one CAP never addressed, and it is the trade-off engineers live with every single day, because partitions are the exception and normal operation is the rule.^[2]

The else branch is concrete. To keep replicas strictly consistent, a write must be acknowledged by other nodes before you confirm it, and those acknowledgements cost round trips. Cross-region, that is tens of milliseconds you cannot optimise away, because it is bounded by distance and the speed of light rather than by your code, which is the same wall described in latency versus bandwidth.

So every day, on every write, in a system with no partition and nothing wrong, you are choosing: wait for the quorum and be slower, or acknowledge locally and be briefly inconsistent. That is the decision that shapes user experience. CAP is silent about it.

Why the Wrong Version Persists

Partly the triangle diagram, which is a genuinely bad piece of information design: it implies three symmetric options and a free choice among them, when one vertex is compulsory and the trade only exists in a rare state.

Partly because “pick two” is memorable and correct-sounding, and the accurate version needs two sentences and a conditional.

And partly because it became an interview question, which rewards reciting the received framing rather than the corrected one. If you are ever asked, the answer that demonstrates you have actually read about this is: P is not optional, the C-versus-A choice binds only during a partition, and the trade-off that matters in normal operation is latency versus consistency.

Where this becomes an architecture decision rather than a definition is in database architecture patterns and SQL versus NoSQL, and the reason you inherit the problem at all is usually a boundary you chose, which is monolith versus microservices.