CAP Theorem & PACELC Without the Confusion

The three letters, precisely

C: Consistency (in CAP, this means linearizability). Every read sees the most recent write, as if there were only one copy of the data. Once anyone sees a new value, nobody sees the old value afterwards. (Linearizability is the strict name for this behaviour.)

⚠️ This is not the "C" in ACID (Lesson 21). It is the same word with a different meaning.

A: Availability. Every request to a working (non-failed) node gets a response. It is not an error and not an endless wait. But the data in the response might not be the latest. (A node is one machine in the system.)

P: Partition tolerance. A network partition is a network failure that splits the nodes into groups, and the groups cannot talk to each other. Partition tolerance means the system keeps working even when the network drops or delays messages between nodes.

What CAP actually says

When a network partition happens, a distributed system (a system of many machines that work together) must choose between consistency and availability.

Why "pick two of three" is misleading

The popular triangle suggests that you can pick CA: consistent and available, but not partition-tolerant. In a real distributed system, you cannot opt out of partitions. Networks will drop packets, switches will fail, cables will be cut, and cloud zones will lose connection to each other. A partition happens to you. It is not a feature that you choose.

So the real choice is:

When a partition happens: C or A?

And when there is no partition, you can have both. CAP says nothing about normal operation. PACELC fills this gap.

(A database with a single node is not a CAP example at all. There is no network between copies that can be split. If that one node dies, the database is simply down.)

CP vs AP behaviour

CP (choose consistency during partitions). Nodes that cannot confirm that they have the latest data refuse requests or return errors until the partition heals. Systems built on consensus (algorithms like Raft and Paxos, where machines vote to agree on one answer) work like this. Only the side with a majority of the nodes can accept writes. The minority side stops.

• Good for: bank balances, inventory counts, leader election (choosing one boss machine), configuration, locks, and anything where a wrong answer is worse than no answer.
• Examples of this behaviour: etcd, ZooKeeper, Consul, Google Spanner, and most relational databases with synchronous failover (a standby copy that always has the latest data takes over).

AP (choose availability during partitions). Every node keeps answering, even if its data may be stale, and keeps accepting writes. The copies are made equal again later. This is called eventual consistency (Lesson 28).

• Good for: shopping carts, social feeds, like counts, product catalogues, DNS, and anything where a slightly old answer is better than an error.
• Examples of this behaviour: Cassandra and DynamoDB in their default modes, Riak, CouchDB, DNS.

Most real systems are tunable, not simply "CP" or "AP"

• Cassandra: with consistency level ONE (one replica must answer), it behaves AP-style. With QUORUM reads and writes (a majority of replicas must answer, so W + R > N, see Lesson 24), it behaves much more like CP.
• DynamoDB: reads are eventually consistent by default (they may return slightly old data). You can ask for strongly consistent reads (and use transactions) when you need them.
• MongoDB: behaviour depends on its "read concern" and "write concern" settings. These settings say how many nodes must confirm a read or a write. It also depends on which node you read from.
• PostgreSQL with replicas: reading from the primary is consistent. Reading from an async replica (a copy that is updated later) may return stale data.

That is why Martin Kleppmann argued, in a well-known article, that we should stop labelling databases as simply "CP" or "AP". The real behaviour depends on the settings, on the operation, and on the kind of failure. It is more useful to ask: "For this operation, with these settings, what happens during a partition?"

PACELC: the everyday trade-off

Partitions are fairly rare. But there is a trade-off that you pay all the time. The computer scientist Daniel Abadi described it with the name PACELC:

If there is a Partition (P), choose between Availability (A) and Consistency (C); Else (E), when running normally, choose between Latency (L) and Consistency (C). (Latency is the time one request takes.)

Why is there a latency cost even without failures? To make sure that every read sees the latest write, nodes must coordinate. They wait for replicas to confirm, or they check with a leader or a majority. This needs extra network round trips (a message there and a reply back). Between regions, each round trip can take 50–200 ms (Lesson 10).

• EL (prefer low latency): answer at once from the nearest copy. The answer might be slightly stale.
• EC (prefer consistency): wait for the coordination. Every read is up to date, but it is slower.

Classifying some systems with PACELC

Each label has two parts. The part before the slash is the choice during a Partition (PA or PC). The part after the slash is the choice Else, in normal operation (EL or EC). These labels are rough and depend on the settings:

Again: use these labels as a way to think, not as fixed truths.

Using CAP and PACELC in design

Ask these questions for each feature, not for the whole system:

1. What happens if two users see different values for a few seconds?
   • Like counts, view counts, "last seen", recommendations: this is acceptable. Choose A and L (availability and low latency).
   • Account balance, stock at checkout, seat booking, usernames: this is not acceptable. Choose C (consistency), even if it is slower or sometimes unavailable.
2. What should the user see during a failure?
   • An error ("please try again")? A read-only mode? Old data with a warning?
3. How far apart are the copies? In the same zone (coordination is cheap) or on different continents (coordination is expensive)?

Many systems mix both. An e-commerce site can serve product pages from AP-style caches and replicas (fast, but maybe slightly stale). It can run checkout and payment on a strongly consistent primary database.