CAP and PACELC as real tradeoffs
When the network breaks you must choose: refuse the write, or accept it and be inconsistent.
What problem does the CAP tradeoff solve?
Networks break apart. A machine cannot tell "you are dead" from "I cannot reach you". When that happens, a distributed system has two options and no third one. Keep answering, with data that may be wrong. Or stop answering.
CAP is that observation, and nothing more. It becomes useful once you stop treating it as a slogan and start applying it to one operation at a time.
What the CAP tradeoff costs you
Every concept in here states a cost. A technique with no price is a technique you have not understood yet — and naming the cost out loud is most of what separates a senior answer from a junior one.
When to reach for the CAP tradeoff, and when not to
Use it when
- Deciding what one specific operation should do when it cannot reach the machine that owns the truth.
- Explaining why the payment path and the like-count path behave differently in the same product.
Do not, when
- Labelling a whole system. It is per operation.
- Explaining ordinary slowness. That is the second half of PACELC, not CAP.
How the CAP tradeoff actually works
- —Only the side that can reach a majority accepts writes. The other side returns an error.
- —No client sees two different truths. No merge to write, no apology to send.
- —Users on the minority side are down, even though their machines are fine.
- —Right for: seats, stock, balances, unique names, anything you cannot un-sell.
- —Both sides keep taking writes and sort it out once the network heals.
- —Everyone stays up. Nobody sees an error page.
- —You now own a merge problem, and sometimes a business problem.
- —Right for: likes, view counts, drafts, presence, carts: anything where "we merged it" is fine.
Stated precisely, the CAP theorem says: when the network splits, you cannot have both consistency and availability. It is not "pick two of three". Splits are not optional; they happen to you. So the choice is between the other two, and only while the split lasts.
PACELC finishes the thought, and its second half is the more useful one day to day. If there is a Partition, choose Availability or Consistency. Else, in the normal case when nothing is broken, choose Latency or Consistency. That second part is where systems differ day to day. A store that confirms a write on one node is fast, and can serve old reads. A store that confirms only after a majority agrees is slower on every write, split or no split. Most people learn only the first half, and then cannot explain why a strongly consistent database is slow on a good day.
So strong consistency costs speed all the time, not only during failures. Name that cost when you choose it.
- Reciting "pick two of three". Network splits are not something you pick.
- Calling a database "AP" or "CP" as if it were fixed. Most are configurable per operation.
- Forgetting the "else" half: consistency costs speed even when nothing is broken.
The the CAP tradeoff follow-up an interviewer will ask
"A whole region is down. What happens to your system?"
It depends which data, and I would answer path by path. Reads: if I have replicas in other regions, reads keep working, possibly with old data, and I would say how old. Writes: if the leader was in the dead region, writes fail until something promotes a new leader elsewhere. That takes seconds to a minute, depending on how eager the failover is. Being eager risks promoting during a brief network hiccup and ending up with two leaders. For contested things like stock, I would rather be down for that region's writes than sell the same seat twice, so I accept being unavailable and say so. For uncontested things like posting a comment or recording a view, I would take the write locally and reconcile afterwards. What I would not do is claim everything keeps working perfectly. That answer tells the interviewer I have not thought about it.
Your turn
Your product has both "add to cart" and "confirm order". Should they make the same CAP choice? Explain in one sentence each.
Learn it from the source
This page gets you interview-ready. These take you to where the idea is actually specified or measured — read them when you want the real depth.
- Please stop calling databases CP or AP ↗Martin Kleppmann on why the CAP classification is less useful than it looks.