Two bank branches share your account. The phone line between them goes down.
You walk into Branch A and ask to withdraw your last ₹10,000. Branch A cannot reach Branch B, so it cannot know whether you already took that money there five minutes ago. It has exactly two choices:
- Refuse to serve you until the line is back. Safe, but you are turned away while the bank is technically open.
- Give you the money and hope you did not also take it from Branch B. Helpful, but you may now have withdrawn ₹20,000 from an account holding ₹10,000.
There is no third option. It cannot be both certainly-correct and certainly-responsive while it cannot talk to the other branch.
That is the CAP theorem in full. Everything else is terminology.
The three letters
- Consistency (C): every read sees the most recent write. All nodes agree on the current value.
- Availability (A): every request receives a response, without error.
- Partition tolerance (P): the system keeps operating even when the network between nodes fails or drops messages.
The theorem says you can guarantee at most two of the three simultaneously.
Diagram, as text
- Network partition leads to Choose C: refuse the request, stay correct
- Network partition leads to Choose A: answer anyway, risk being stale
CP: choose correctness, sacrifice answering
A CP system, when it cannot reach its peers, refuses to serve rather than risk being wrong. It returns an error or blocks until the partition heals.
The branch that turns you away is CP. It would rather be unhelpful than let you overdraw.
Choose CP when being wrong is worse than being down:
- Bank balances and payments — double-spending is unacceptable.
- Inventory for scarce goods — selling the last concert ticket twice creates a problem you cannot undo.
- Anything where two users must not both win the same resource.
Commonly run this way: relational databases in strongly-consistent configurations, ZooKeeper, etcd, MongoDB with majority reads and writes.
AP: choose answering, sacrifice agreement
An AP system always responds, even when isolated. It serves what it knows, accepting the answer may be slightly out of date, and reconciles once the network returns.
The branch that hands you the money is AP.
Choose AP when being briefly stale beats being unavailable:
- Social feeds — a friend's post arriving three seconds late is invisible; an error page is not.
- Product catalogues and content sites — a slightly old description is harmless.
- Metrics, logs, view counts — approximate is fine.
Commonly run this way: Cassandra, DynamoDB in its default mode, CouchDB, most of DNS.
Eventual consistency, in plain terms
AP systems are usually described as eventually consistent: if writes stop, all copies converge on the same value given enough time. "Eventually" is typically milliseconds, occasionally seconds.
The everyday example is a video view count that sits at 301 for a while, then jumps. Nothing is broken — different servers hold slightly different counts and are still reconciling. Nobody is harmed by a temporarily wrong view count, so the trade is obviously worth it.
Now picture that same behaviour on your bank balance. Identical mechanism, completely unacceptable outcome. The technology is not good or bad; the fit to the domain is what matters.
It is a spectrum, and it is per-operation
The strict "C or A" framing simplifies in two ways worth knowing.
First, it is a dial, not a switch. Many databases let you choose per query how many replicas must agree before answering. Ask one replica for a fast, possibly stale answer; ask a majority for a slower, near-certainly correct one.
Second, the choice belongs to the operation, not the company. The same product deliberately mixes both:
| Operation on a shopping site | Choice | Why |
|---|---|---|
| Browsing products | AP | A slightly stale price beats an unavailable shop |
| Adding to cart | AP | Never block a customer from trying to buy |
| Taking payment | CP | Charging twice is unacceptable |
| Final stock check | CP | Overselling the last item has real-world cost |
A good design answer is rarely "we are an AP system". It is "feed reads are AP because staleness is invisible there, and checkout is CP because double-charging is not".
What CAP does not say
It says nothing about normal operation. When the network is healthy you can have both consistency and availability. CAP constrains you only during a partition, and a well-run system is almost never partitioned.
"Available" has a strict meaning here. It means every non-failing node answers every request. A system replying in 30 seconds is available under CAP and useless in practice — which is why the PACELC extension adds that even without a partition, you still trade latency against consistency.
It is not permission to abandon correctness. "We are eventually consistent" sometimes gets used to wave away real bugs. Eventual consistency is a precise property with defined convergence, not a synonym for "sometimes wrong".
Check your understanding
Common mistakes
Saying "we picked CA". This signals you have not grasped that partitions are imposed on you. Unless the system is a single node, CA is not on the menu.
Applying one choice to the whole product. Real systems mix CP and AP per operation; blanket answers skip the interesting reasoning.
Assuming eventual consistency is always fine. Ask what a stale read actually causes. A stale view count is nothing; a stale balance is fraud.
Forgetting the partition heals. The hard engineering in AP systems is not staying up during the split — it is resolving conflicting writes afterwards. Have an answer for who wins.
Practice
You are designing a hotel booking system for a chain with datacentres in London and Singapore. List three operations, decide CP or AP for each, and say what breaks if you chose the other way.
Write your own answer first, on paper or in a note. Then compare.
Show a hint
Ask of each operation: if two copies disagree for thirty seconds, who notices, and can the damage be undone with an apology?
Show a strong answer
A reasonable split:
- Confirming a booking — CP. A room is a scarce resource. Two guests holding the same room for the same night cannot both be honoured, and no later reconciliation fixes the family standing in reception at midnight. If this were AP you would oversell and pay for the apology in refunds and reputation.
- Searching for available rooms — AP. A search result that is thirty seconds stale shows a room that has just gone. The cost is one disappointed click, and the booking step catches it. If this were CP, a network split between regions would take search down worldwide — turning a minor annoyance into a total outage.
- Loyalty points balance — AP, with a caveat. Points can converge later. But redeeming points spends a scarce balance, so redemption should be CP even though display is AP.
The general shape: reads that inform are AP, writes that consume a finite resource are CP.
Your team runs an AP inventory service. The partition heals and two regions have both decremented the same stock count from 10 to 9 independently. The true remaining stock is 8. Describe two strategies for resolving this and the cost of each.
Write your own answer first, on paper or in a note. Then compare.
Show a hint
The hard part of AP is never staying up during the split — it is what you do afterwards.
Show a strong answer
Two workable strategies:
- Last-write-wins. Keep whichever update has the later timestamp and discard the other. Cheap to implement and easy to reason about, but here it is simply wrong: it records stock as 9 when 8 units remain, so you will eventually sell an item you do not have. Last-write-wins is safe for values that overwrite (a display name) and unsafe for values that accumulate.
- Model the change, not the value. Store decrements as separate events rather than storing a count. On heal, both decrements survive and the total is derived as 10 − 1 − 1 = 8. This is what a counter CRDT does. It costs more storage and makes reads more expensive, but it converges to the correct answer without a coordinator.
A third option worth naming: accept a small oversell and compensate. Many retailers do this deliberately, treating rare oversells as a business cost rather than paying for coordination on every write.
Key takeaways
- Once data lives on more than one machine, partitions are inevitable, so P is not optional. The real choice is C or A during a partition.
- CP refuses to answer rather than risk being wrong — right for money, inventory, and any scarce resource.
- AP always answers and reconciles later — right for feeds, catalogues and metrics where staleness is invisible.
- Eventual consistency means copies converge once writes stop; whether that is acceptable depends entirely on the domain.
- The choice is per operation, not per company.
- CAP constrains behaviour only during a partition; the trade of latency against consistency applies the rest of the time.
Next we turn all of this into a repeatable method for attacking any system design question under interview pressure.
Further reading
- Eric Brewer, "Towards Robust Distributed Systems" (PODC 2000 keynote) — where the conjecture was first stated.
- Seth Gilbert and Nancy Lynch, "Brewer's Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services" (ACM SIGACT News, 2002) — the formal proof.
- Eric Brewer, "CAP Twelve Years Later: How the 'Rules' Have Changed" (IEEE Computer, 2012) — the author's own correction of the "pick two" reading.
- Daniel Abadi, "Consistency Tradeoffs in Modern Distributed Database System Design" (IEEE Computer, 2012) — introduces PACELC, which extends CAP to the latency trade-off that applies when there is no partition.
- Martin Kleppmann, Designing Data-Intensive Applications (O'Reilly, 2017), chapter 9 — consistency and consensus in practice.