The CAP theorem and PACELC

The three letters

• Consistency (C): every read sees the most recent write, as if there were one copy of the data. This is the strong form called linearisability.
• Availability (A): every request to a working node gets a non-error response, without waiting forever.
• Partition tolerance (P): the system keeps operating even when messages between nodes are lost, so the cluster is split into groups that cannot talk.

The theorem, proposed by Eric Brewer and later proved formally, is often stated as "pick two of three". That slogan is misleading.

What CAP really says

In any system spread over a network, partitions will happen: a switch fails, a link is cut, or a cloud zone is isolated. You cannot opt out of P. So the real choice is what to do during a partition:

• CP: keep consistency. Nodes that cannot confirm they have the latest data refuse writes or reads, returning errors or timing out. Banking ledgers and configuration stores such as etcd behave this way.
• AP: keep availability. Every node keeps answering, even if its data might be stale, and the groups reconcile later. Shopping baskets, social feeds and DNS lean this way.

When there is no partition, a well-built system can offer both C and A. CAP only describes the behaviour under failure.

PACELC: the everyday trade-off

Daniel Abadi pointed out that partitions are rare, but a trade-off exists all the time. PACELC reads: if there is a Partition, choose A or C; else, choose Latency or Consistency.

Keeping replicas strongly consistent means waiting for other nodes to confirm each write, which adds delay, especially across regions. Letting a write complete locally and copying it later is faster but allows stale reads.

Many databases let you choose per query, for example by setting how many replicas must acknowledge a read or write. This makes the trade-off a design decision for each piece of data rather than a fixed product label.

Applying it at work

1. List the data your service stores and ask what harm a stale read would cause.
2. For money, stock counts and permissions, prefer consistency and accept errors during partitions.
3. For likes, recommendations and caches, prefer availability and low latency.
4. Document what users see during a partition, and test it (see chaos testing).

Tip: if an exam asks you to "pick two", explain that P is not optional in a real network, so the choice is C or A during a partition.

A common mistake is calling a single-node database "CA". A single node avoids partitions only because it is not distributed; it also has no redundancy if that node fails.