CAP theorem

Why it matters

Every datastore with more than one node will, at some point, have nodes that cannot talk to each other. In that moment it must do one of two things: keep answering with data that might be stale, or refuse to answer until it knows the truth. That is the whole of the CAP theorem, and it is the reason "which database" is a product question. Misquoting it is also one of the most common ways to lose credibility in a design interview, so it is worth getting precisely right.

The idea

CAP names three properties of a distributed data system:

• Consistency: every read returns the most recent write or an error. (This is linearizability, a stronger claim than the C in ACID.)
• Availability: every request to a non-failed node gets a non-error response, without the guarantee that it is the latest.
• Partition tolerance: the system keeps operating when messages between nodes are lost or delayed.

The theorem says you cannot have all three at the same time during a partition. Since partitions are a fact of networks, not a choice, the real decision is what to do when one happens: give up consistency (stay available, serve possibly stale data) or give up availability (refuse or block until the partition heals).

What CAP does not say

It does not say "pick two of three" as a design-time menu. Partition tolerance is not optional, so every real system is CP or AP in the moment of a partition. It does not apply the same way to every operation: a system can be CP for account balances and AP for the activity feed. And it says nothing about behaviour when the network is healthy, which is most of the time, and which is where the next idea comes in.

PACELC: the useful extension

PACELC reads: if there is a Partition, choose Availability or Consistency; Else, when running normally, choose Latency or Consistency. Even with a healthy network, waiting for every replica to acknowledge a write costs latency; answering from the nearest replica may return stale data. That everyday trade is the one you make far more often than the partition one.

	CP-leaning	AP-leaning
During a partition	Refuses or blocks writes on the minority side	Keeps accepting reads and writes everywhere
Normal operation	Synchronous replication, higher write latency	Asynchronous replication, lower latency, eventual consistency
Conflicts	Prevented up front	Resolved later: last-writer-wins, vector clocks, CRDTs
Examples	Single-leader relational databases with sync replicas, ZooKeeper, etcd, Spanner	Dynamo-style stores, Cassandra with low consistency levels, DNS, most caches
Fits	Money, inventory, uniqueness, leader election	Feeds, counters, presence, shopping carts, anything users forgive being slightly off

Tunable consistency

Many stores let you pick per request. Quorum systems with N replicas accept a write once W replicas acknowledge and serve a read from R replicas; when R plus W exceeds N, a read overlaps at least one node with the latest write and you get strong reads at the cost of latency. Set R or W low and you get speed and availability with staleness. The knob is per operation, which is exactly how products need it.

Trade-offs

Choosing CP buys correctness with latency and with the possibility of refusing requests during incidents. Choosing AP buys uptime and speed with the work of reasoning about stale reads and resolving conflicts, which leaks into application code and product behaviour. The mistake is choosing once for the whole system; the skill is choosing per data type and saying why.

In an interview

Never say "pick two". Say: "Partitions will happen, so for balances I need consistency and I accept that writes may fail during a partition; for the feed I need availability and I accept eventual consistency, with last-writer-wins on conflicts. In normal operation I would read balances from the leader and feed items from replicas, which is the PACELC latency trade." That answer shows you understand both the theorem and its limits.