CAP Theorem

The CAP theorem, first proposed by Eric Brewer in 2000 and later formally proven, states that a distributed data system can only guarantee two out of the following three properties at the same time:

• Consistency (C) — every read receives the most recent write, or an error. All nodes see the same data at the same time.
• Availability (A) — every request receives a (non-error) response, without guarantee that it contains the most recent write.
• Partition Tolerance (P) — the system continues to operate despite network partitions (messages between nodes being dropped or delayed).

The theorem's real teeth are in a detail that's easy to skim past: partitions are going to happen. Networks are unreliable — cables get cut, switches fail, packets get dropped or delayed. Given enough machines and enough time, a partition is not an edge case you can design away; it's a when, not an if. That means P is not really a choice — any distributed system that's actually distributed (spans more than one node, ever) has to handle partitions. The real decision CAP forces on you is what to do during a partition: choose C or choose A.

The decision that actually matters

System Design Lab

• Choosing CP means that during a partition, nodes that can't confirm they have the latest data will refuse to answer (or block) rather than risk returning something wrong. Systems like ZooKeeper, etcd, and traditional single-leader relational databases configured for strict consistency lean this way — they'd rather be unavailable than wrong.
• Choosing AP means every reachable node keeps answering requests even if it can't confirm it has the latest write, accepting that different nodes might temporarily disagree. Systems like Cassandra, DynamoDB (in its default configuration), and most DNS infrastructure lean this way — they'd rather give you a possibly-stale answer than no answer.

Neither choice is "correct" in the abstract — it depends entirely on what the application can tolerate. A bank ledger balance probably wants CP (better to reject a transaction than post it against the wrong balance). A social media "like" counter can happily be AP (a slightly stale count is a non-issue, and refusing to load the page over it would be absurd).

Why "we chose CA" is a red flag

You'll sometimes hear systems described as "CA" (consistent and available, but not partition tolerant). Be careful with this in an interview: it usually only makes sense for a system that runs on a single node, or that has explicitly decided it will simply go fully down during a partition rather than choosing between C and A. For any real multi-node system, claiming "CA" without qualification tends to signal you haven't fully internalized that P isn't optional at scale — it's worth naming this nuance if it comes up, since it's a well-known critique of how CAP gets oversimplified in casual conversation.

What CAP doesn't tell you

CAP is a useful framing but a narrow one — it only describes behavior during a network partition, and only in terms of a binary "consistent or available" choice. Two things worth knowing so you don't over-apply it:

• Most of the time, there's no partition, and the real-world tradeoff you're actually managing day to day is closer to latency vs. consistency — even without a partition, 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 nuance is captured by the follow-up "PACELC" framing: if Partitioned, choose A or C; Else, choose Latency or Consistency.
• "Consistency" in CAP means something narrower and stricter than the "C" in ACID database transactions — they're related but not the same guarantee, and conflating them is a common mistake worth avoiding out loud.

The practical payoff for an interview: when you pick a database or replication strategy for a design, say explicitly what you're optimizing for under partition, and why the application's requirements point that way — that's a much stronger answer than naming "CAP theorem" as a fact and moving on.

Choosing AP over CP: pros and cons

Pros

• ✓Stays responsive even during a network partition
• ✓Better experience for read-heavy, tolerant-of-staleness workloads
• ✓Higher overall availability — no request is ever flatly refused

Cons

• ✕Reads can return stale or divergent data across nodes
• ✕Needs explicit conflict-resolution logic (e.g. last-write-wins, vector clocks)
• ✕Wrong choice for anything that needs strict correctness, like a ledger balance

Further Reading

• CAP Twelve Years Later: How the "Rules" Have Changed — Eric Brewer's own retrospective, clarifying common misconceptions about the theorem he originally proposed.
• Please Stop Calling Databases CP or AP by Martin Kleppmann — a widely cited critique that sharpens exactly what CAP does and doesn't guarantee.