What you'll learn
Quick Answer
When a network partition splits your system, you must choose between consistency (refuse to answer with possibly stale data) and availability (answer anyway). You cannot have both during a partition, and partitions are unavoidable.
The three terms, precisely
The common summary — "pick two of three" — misleads, because the three are not equivalent choices.
- Consistency — every read receives the most recent write. Note this is not the C in ACID, which means something different. Here it means all nodes agree.
- Availability — every request receives a response, without guaranteeing it is the latest data.
- Partition tolerance — the system continues operating when network messages between nodes are lost or delayed.
The crucial point: partition tolerance is not optional. Networks fail — cables are cut, switches misbehave, a data centre becomes unreachable. In any system spanning more than one machine, partitions will occur.
So you do not pick two. You accept partition tolerance, and the theorem tells you what happens during a partition: you choose consistency or availability, and cannot have both.
What that means concretely
Two database nodes, in different regions, normally replicating. The link between them fails, so each still serves users but cannot reach the other.
A write arrives at node A. What should node B do when it receives a read?
Choose consistency: node B refuses to answer, because it cannot know whether A has newer data. Users hitting B see an error. The system is correct and partly unavailable.
Choose availability: node B answers with what it has, which may be stale. Users get a response, possibly wrong. The system is available and temporarily inconsistent.
There is no third option, and that is the whole content of the theorem. You cannot answer correctly with information you do not have.
Which is right depends entirely on the data. For a bank balance, refusing is correct — showing a wrong balance is worse than showing an error. For a social feed, answering with slightly stale posts is obviously better than an error page.
How real systems land
Consistency-leaning: traditional relational databases in a single-primary configuration, and systems built around consensus protocols. When the primary is unreachable, writes stop rather than diverge. HBase and ZooKeeper are usually described this way.
Availability-leaning: Cassandra and DynamoDB accept writes on whichever node is reachable and reconcile afterwards, which is where eventual consistency comes from — given enough time without new writes, all nodes converge.
Two important caveats.
Many systems are tunable per operation rather than fixed. Cassandra lets you require a quorum for a specific read, choosing consistency for that query while staying available for others. So "which category is this database" is often the wrong question.
And the trade-off only applies during a partition. Most of the time the network works and a well-designed system provides both. CAP describes the failure mode, not everyday operation — which is what "pick two" obscures most badly.
PACELC: the part CAP leaves out
CAP says nothing about normal operation, which is where systems spend nearly all their time. PACELC extends it usefully.
The statement: if there is a Partition, choose Availability or Consistency; Else, choose Latency or Consistency.
The second half is the everyday trade. Even with a healthy network, guaranteeing that every read sees the latest write means coordinating between nodes — and coordination costs time. A system that confirms a write with every replica before acknowledging is slower than one that acknowledges immediately and replicates afterwards.
This is the trade-off you actually feel day to day: stronger consistency costs latency. A read replica serving stale data by a few hundred milliseconds is fast; a read that must go to the primary is correct and slower.
Mentioning PACELC in a system design interview signals you understand that CAP is not the whole picture, which is a genuinely good sign.
Using this in practice
The useful application is not classifying databases. It is asking, for each piece of data: what should happen if we cannot be sure this is current?
- Payments, inventory during checkout, seat booking — consistency. An error is better than double-selling. This is why booking systems need explicit handling regardless of database choice.
- Feeds, view counts, recommendations, search results — availability. Slightly stale is fine and an outage is not.
- User profiles, settings — usually availability, with eventual convergence.
Most real applications need both, for different data. That is normal, and it is why systems mix a relational database for transactional data with something else for high-volume tolerant data.
In interviews the good answer is never "I would use an AP database". It is "bookings need consistency because double-booking is unacceptable, so I would use a transaction with row locking there; the browsing feed can be eventually consistent and served from a cache". That reasoning is the point of knowing CAP at all.