CAP theorem
A bank keeps your balance in two data centres, one in Mumbai and one in Chennai, so that losing one building does not lose your money. A road crew outside Pune puts a digger through the fibre that connects them. Both data centres are still running. They just cannot talk to each other.
Your account has ₹5,000 in it. In the same minute, your card is used at an ATM in Mumbai and your partner uses the joint card at an ATM in Chennai. Each ATM has two honest options: say no, or hand over cash without knowing what the other side just did.
That choice is the CAP theorem. Everything else is detail.
The link between your two data centres is down for ten minutes. For a bank balance, would you rather refuse withdrawals or risk paying out twice? Now answer the same question for a like count on a reel. Did your answer change, and why?
The three letters, in plain words
Consistency means everyone sees the same data. Once a write is confirmed, any replica you ask gives you that write. Nobody ever reads an old value.
Availability means every request gets a real answer. Not an error, not a spinner that never ends. Any replica that is still running must reply.
Partition tolerance means the system keeps working when the network between replicas drops messages. A cut cable, a bad router, a cloud zone that goes quiet. That gap is called a partition.
You will hear CAP described as “pick any two of three”. That phrasing causes most of the confusion, because the P is not yours to give up. Networks break whether you allow it or not. So the real statement is shorter:
When a partition happens, you must choose between consistency and availability.
Make the choice yourself
Three replicas. A and B sit together, C is on its own. Cut the link, then decide what C should do with the request that lands on it. Run all four scenarios. The cable is the same every time and the right answer is not.
If you ran all four, you noticed the pattern. You refuse when a mistake cannot be undone, like money leaving or one seat sold twice. You answer anyway when the two sides can be combined afterwards, like two carts or two sets of likes.
Why you cannot have both
Look at replica C during the cut. A write happened on the other side and C does not have it. Nothing can get it there. So when a read or a write lands on C, only two things are possible.
C answers. Then it is answering without the latest data, so the system is no longer consistent.
C refuses. Then a running server turned a user away, so the system is no longer available.
There is no third move, and no amount of clever engineering creates one, because the missing information is on the far side of a cable that is not carrying anything.
People sometimes say a single Postgres server is “CA”. It is, in a boring way: there is only one copy, so there is no network between copies to break. The moment you add a second replica for safety, you are a distributed system and the choice is back. If someone offers you all three, ask what happens to a write on the minority side.
CP and AP, with names
A system that refuses when unsure is called CP. A system that answers anyway is called AP.
CP in practice. ZooKeeper and etcd need a majority of nodes to agree before they accept a write. The side with fewer nodes stops accepting writes until the link returns. MongoDB does the same thing with its primary: a primary that cannot see a majority steps down. These are the systems you trust with “who is the leader” and “who holds the lock”.
AP in practice. Cassandra and Riak, both built on ideas from Amazon’s 2007 Dynamo paper, keep taking writes on both sides and reconcile afterwards. DNS is the oldest example: your resolver will happily give you an address that changed ten minutes ago, because a slightly stale answer beats no internet.
The choice is per feature, not per company
This is the part that makes you sound like you have built something. One product makes both choices, in different places.
Figure 1 is a shopping app. Browsing and paying go to different stores on purpose.
Now try it on things you use. Decide CP or AP for each one before you reveal it. The question to ask yourself is always the same: if both sides say yes, can I fix it later?
Real banks do not pick pure CP for ATMs. Eric Brewer, who proposed CAP, pointed this out in 2012: an ATM that loses its link usually keeps working, with a low withdrawal limit, and settles up when the link returns. If you overdraw, the bank charges you a fee. That is choosing availability and then putting a ceiling on how wrong you can be. It is the most useful CAP answer there is: you do not have to pick an extreme, you can pick a limit on the damage.
The rest of the time
Partitions are rare. On a normal day every replica can reach every other one. So if CAP only speaks about partitions, what about all that normal time?
There is an extension called PACELC (say “pass-elk”) that covers them. Read it as a sentence: if there is a Partition, choose A or C. Else, choose Latency or Consistency.
The second half is the one you pay every day. Say a user in Mumbai saves a write. You can confirm it as soon as the Mumbai replica has it, in a few milliseconds. Or you can wait until the Singapore replica has it too, which adds a round trip of about 60 ms to every single write. The first is fast and can lose the write if Mumbai dies in that instant. The second is safe and slower for everyone, always.
So even with a perfect network, stronger consistency costs you waiting time. The replication and quorums page has the dials that set this.
Consistency is a dial, not a switch
“Consistent” and “eventually consistent” are the two ends. The useful settings are in between.
Strong consistency. Once a write is confirmed, every reader sees it. This is what a balance needs.
Read your own writes. You always see your own changes straight away. Other people may see them a moment later. This is what a profile edit needs, and it is much cheaper than strong consistency.
Eventual consistency. If the writes stop, all replicas end up agreeing a moment later. In between, different people may see different values. This is fine for like counts, view counts and feeds.
The C in CAP is not the C in ACID. In ACID it means your data obeys its rules, such as “a balance is never negative”. In CAP it means all replicas show the same value. And the A in CAP is stricter than “four nines of uptime”: it means every running node must answer, even the one that is cut off.
Trade-offs
| Choice | What you gain | What you pay | Pick it when |
|---|---|---|---|
| CP: refuse when unsure | Nobody ever sees or acts on wrong data. Nothing to clean up after the link returns. | Users on the cut off side get errors until the partition ends, even though your servers are running. | Money, inventory, unique names, locks and leader election. Anything where two yeses cannot be merged. |
| AP: answer anyway | Every user gets a response during the outage. The product keeps working. | The two sides drift apart, and you need a rule for combining them afterwards. | Carts, likes, feeds, presence, catalogues. Anything where being briefly out of date is harmless. |
| AP with a limit | Stays available, and the worst case has a known size, such as a ₹10,000 offline withdrawal limit. | You must accept some loss inside the limit and build the settling up step. | Money or stock where an error page costs more than a small, bounded mistake. |
| Tunable per request | One database serves both kinds of data. Cassandra lets each query ask for one replica, a quorum or all. | Every developer has to choose correctly on every query, and a wrong default is a silent bug. | A product with a mix of critical and casual data and a team that understands the dial. |
Interview replay
Checkpoint
1. Why is "pick any two of C, A and P" a misleading way to state CAP?
2. A replica is cut off from the others and receives a write. In a CP system, what happens?
3. You are storing "items in my wishlist". During a partition, which choice fits, and why?
- During a partition you get C or A, never both. The rest of the time you have both.
- Refuse when two yeses cannot be merged (money, seats, usernames, locks). Answer when they can (carts, likes, feeds).
- A majority is more than half. With 3 replicas, the side with 2 keeps working and the side with 1 stops.
- PACELC: no partition, still a trade. Waiting for a far replica costs about 60 ms on every write between Mumbai and Singapore.
CAP says that when the network splits replicas apart, each one has to either refuse requests to stay consistent or answer with possibly old data to stay available. You cannot avoid partitions, so it is really a choice between consistency and availability, and only while the partition lasts. I make that choice per feature, not per system. The test I use is whether two conflicting yeses can be merged afterwards. Payments, seat assignment and unique usernames cannot, so they are CP and I accept errors during a partition. Carts, likes and feeds can, so they are AP and I reconcile when the link returns. When there is no partition there is still a trade between latency and consistency, because waiting for a distant replica slows every write.
