CAP Theorem

The moment your data lives on more than one machine, physics imposes a trade-off. The CAP theorem names it. It sounds abstract, but it comes down to one concrete question you'll answer in almost every design: when two parts of your system can't talk to each other, do you keep answering (and risk stale data) or refuse to answer (and stay correct)?

The three letters

• Consistency — every read returns the most recent write. All nodes agree.
• Availability — every request gets a (non-error) response, even if some nodes are unreachable.
• Partition tolerance — the system keeps working when the network drops messages between nodes.

The theorem says you can have at most two of the three at once.

Why it's really a choice between C and A

Here's the part that trips people up: in a real distributed system, partitions will happen — networks fail, packets drop, a data centre link goes down. You don't get to opt out of partition tolerance. So the real question isn't "pick two of three." It's: when a partition happens, which do you sacrifice — C or A?

• Choose consistency (CP): during a partition, refuse reads/writes that can't be confirmed, rather than serve possibly-stale data. The system may return errors, but it's never wrong.
• Choose availability (AP): during a partition, keep serving from whatever node you can reach, accepting that it might be slightly behind. It's always up, but it can be stale.

When the network is healthy (most of the time), you get both. CAP only bites during the partition.

Decide per feature, not per system

The trap is answering CAP once for the whole system. Real products mix both, feature by feature, based on what a wrong answer costs:

A bank shows a balance: being briefly unavailable is annoying, but showing the wrong balance is dangerous — so it leans consistent. A social network shows a like count: being off by three for a moment is invisible, but going down is a real outage — so it leans available and lets the count catch up.

This is the same trade as replicas and caching

You've already met this trade-off wearing other hats:

• A read replica that lags is an availability/consistency choice — you serve a fast, possibly-stale read instead of waiting on the primary.
• A cache is "slightly wrong on purpose" for speed — the staleness window is you choosing availability over strict consistency for that data.

CAP is just the formal name for the decision you make every time you add a copy of data anywhere.

A note on "eventual consistency"

AP systems are often called eventually consistent: after a write, replicas converge to the same value eventually — usually within milliseconds. For much of the web that's perfectly fine. The engineering question is whether your feature can tolerate the window between "written" and "visible everywhere." For a feed, yes. For a seat sale, no.

What to say in an interview

Don't recite the definition — apply it to a specific feature and justify the cost:

"For the checkout, I need consistency: I'd read seat availability from the primary inside the purchase transaction, even if that means a failure during a partition, because overselling is worse than a retry. For the public event page showing how many seats are left, I'll favour availability and serve a slightly stale number from a replica or cache — a visitor seeing '42 left' when it's really 40 is fine."

---

Next up: Database Indexing — making the consistent reads above fast.