Skip to main content

What Is the CAP Theorem? A Simple Explanation

· 3 min read
System Design Lab
Free system design course

The CAP theorem gets summarized so often as "pick two of three" that the actual, useful part — what it forces you to decide, and when — gets lost. Here's the version that's actually useful in a system design interview.

The three properties​

  • Consistency (C) — every read gets the most recent write, or an error. All nodes see the same data at the same time.
  • Availability (A) — every request gets a non-error response, with no guarantee it's the most recent write.
  • Partition Tolerance (P) — the system keeps working even when network messages between nodes are dropped or delayed.

The part everyone skims past: P isn't optional​

Partitions will happen — cables get cut, switches fail, packets get dropped. Any system that spans more than one machine has to handle that reality eventually. Which means P isn't really a choice you get to opt out of. The actual decision CAP forces on you is what happens during a partition: do you choose consistency, or do you choose availability?

  • Choose C: nodes that can't confirm they have the latest data return an error rather than risk serving something stale.
  • Choose A: every node keeps answering requests, even if some of them serve slightly outdated data.

There's no third option where you keep both during an actual partition — that's the whole theorem.

The nuance most explanations miss​

Most of the time, there's no partition happening. The tradeoff you're actually managing day to day is closer to latency vs. consistency: requiring every replica to confirm a write before acknowledging it (strong consistency) adds latency compared to acknowledging as soon as one node has it (eventual consistency). This is captured by the follow-up framing, PACELC: if Partitioned, choose Availability or Consistency; Else, choose Latency or Consistency.

One more distinction worth being precise about: "consistency" in CAP is a narrower, stricter guarantee than the "C" in ACID database transactions. They're related, but conflating them is a common mistake.

Why this matters in an interview​

"We chose AP for availability" is a weak answer on its own. A stronger one names what specifically breaks during a partition, and why the application can tolerate it — e.g., a social media feed can serve slightly stale data during a partition (choose A), but a payments ledger generally can't (choose C). Naming the actual tradeoff, not just citing the theorem, is what shows real understanding.

Go deeper​

The full lesson has a decision diagram, walks through why "CA" systems are mostly a red flag in interview answers, and covers the pros/cons of choosing AP over CP with concrete examples:

👉 Read the full CAP Theorem lesson — part of the free System Design Lab course.