CAP theorem explained: an interactive network partition simulator
The CAP theorem says that when a network partition cuts a distributed system in two, it has to choose between consistency, every read sees the latest write or gets an error, and availability, every request gets a real answer. Partitions are not optional, so the real choice is what to give up while one lasts. PACELC adds the other half: even when there is no partition, you trade latency for consistency.
The playground sells the last 16 units of an item from two regions, East and West, for a minute, and cuts the network between them for twenty seconds. Choose a design that stays consistent (CP) or one that stays available (AP), and count what is sold and what fails.
One leader, in East, owns the count. When the network between the regions is cut from 20 s to 40 s, West cannot reach it, so West’s 4 orders in that time fail: the system gives up availability to stay consistent. East keeps selling, and exactly 16 units are sold, never more than the 16 there are.
What C, A and P mean
- Consistency: every read returns the most recent write, as if there were one copy of the data. Formally, linearizability.
- Availability: every request to a node that is up gets a response that is not an error, however long the partition lasts.
- Partition tolerance: the system keeps working when messages between nodes are lost or delayed.
A system spread over a network cannot rule partitions out, so “CA” is not a real option: a system that assumes the network never fails simply behaves badly when it does. The theorem only constrains behaviour during a partition; the rest of the time a system can be both consistent and available.
CP: refuse rather than be wrong
A CP system keeps one source of truth and stops serving whatever cannot reach it. In the first preset the stock count lives with a leader in East. While the network is cut, West cannot reach it, so West’s 4 orders in that time fail, and exactly 16 units are sold. That is the right trade for inventory, payments, account balances and unique usernames, where a wrong answer costs more than no answer. Leader-based databases and coordination services such as ZooKeeper and etcd behave this way: the side without a majority stops accepting writes.
AP: answer now, reconcile later
An AP system lets every region keep working on its own copy and merges the copies when the network returns. In the second preset both regions keep selling what they believe is left, 19 units are sold of 16, and after the cut both copies show −3: three customers hold orders that cannot be filled, and the business has to cancel, apologise or find stock. That is acceptable for shopping carts, likes, view counts, social feeds and DNS, where a stale or merged answer is better than none. Dynamo-style stores are built this way, and Cassandra and DynamoDB default to it.
PACELC: the cost without a partition
Partitions are rare; latency is constant. PACELC says: if there is a Partition, choose Availability or Consistency; Else, choose Latency or Consistency. In the third preset nothing goes wrong, yet every order from West waits 72 ms for a round trip to the leader in East, against 2 ms selling locally. Many systems that choose consistency also pay for it in every request, and many that choose availability do so as much for the latency as for partitions.
It is a choice per operation, not per system
Real systems mix both. An online shop can keep the cart and product pages available and eventually consistent, but reserve stock and take payment through a single leader that refuses when it cannot be sure. Databases often let you choose per request: in Cassandra, reads and writes at quorum behave consistently, and at ONE they stay available with possibly stale data.
In a system design interview
Do not just say “we choose AP”. Say which operations, and what happens during a partition: “Seat holds go through a single leader per event, so a region cut off from it cannot sell seats; it shows the event as temporarily unavailable rather than risk double-selling. Browsing, search and the seat map are served from local replicas and can be a few seconds stale.” Expect the follow-ups: what users see during the partition, how AP conflicts are resolved, and the latency cost of the consistent path.
Read the guide to the CAP theorem, try read-your-writes consistency for a weaker guarantee that is often enough, or watch a strong candidate design a ticketing system, where overselling is the failure to avoid.
Questions people ask
What is the CAP theorem?
A result about distributed systems: when a network partition separates nodes, a system cannot be both consistent, with every read seeing the latest write, and available, with every request getting a non-error response. It must give up one of them for as long as the partition lasts.
What do consistency, availability and partition tolerance mean in CAP?
Consistency means linearizability: the system behaves as if there were one copy of the data and every read sees the latest write. Availability means every request to a working node gets a non-error response. Partition tolerance means the system keeps operating when messages between nodes are lost or delayed.
Why can a distributed system not be CA?
Because partitions are not something a system spread across a network can rule out: links fail, switches drop packets and nodes stall. Claiming CA only means the system has no defined behaviour during a partition. The practical choice is between consistency and availability while a partition lasts.
What is the difference between CP and AP systems?
During a partition, a CP system refuses requests it cannot answer correctly, such as writes on the side without the leader or a majority. An AP system keeps answering on both sides from local copies and reconciles them afterwards, accepting stale reads and conflicting writes. Inventory and payments usually need CP; carts, feeds and counters usually tolerate AP.
What is PACELC?
An extension of CAP: if there is a Partition, a system chooses Availability or Consistency; Else, when the network is healthy, it chooses Latency or Consistency. Keeping replicas consistent means waiting for coordination, often across regions, on every request, so consistency costs latency even when nothing is failing.
Is Cassandra CP or AP?
By default it behaves as AP: any replica can accept writes and conflicts are resolved by timestamp. But consistency is chosen per request: reads and writes at QUORUM overlap and give up availability when a majority of replicas is unreachable, while ONE stays available with possibly stale data. Many databases are tunable in the same way.
How do you choose between consistency and availability?
Per operation, by asking what a wrong answer costs compared with no answer. Overselling stock, double-spending money or giving two people the same username is worse than a brief error, so those paths should be consistent. Showing a slightly stale feed, count or cart is better than an error, so those can be available and reconcile later.