Interview Prep Zoneby CuriouserLabs

Question 1 of 5 · senior level

What does the CAP theorem actually claim — and what do most engineers get wrong about it?

🎤 Say this first

CAP says that when a network partition happens, a distributed store must give up either consistency (linearizability — every read sees the latest write) or availability (every non-failing node returns a non-error response). The universal misreading is 'pick 2 of 3': P is not a choice, it's a fact about networks — you can't opt out of packets being dropped, so real systems are CP or AP, never 'CA'. Two further corrections: CAP's C is linearizability, not ACID's C; and CAP only constrains you during a partition, which is a rare event. That's why PACELC is the more useful tool: if Partition, choose A or C; Else (the 99.9% of the time the network is fine), choose Latency or Consistency. The everyday trade-off lives in that second branch.

The full picture

🎬 CAP: what a partition actually forces you to choose

1 / 5
one shared historyNode Ax = 0Node Bx = 0replicationClient 1Client 2PACELC: no partition? Then the real trade is Latency vs Consistency.

Two replicas of the same key, connected by a network link. While the link is healthy they share one history — consistency and availability are both free.

One partition, two choices: refuse the write (CP) or accept it on both sides and diverge (AP).
SystemPACELCWhat it means in practice
Postgres / MySQL (single leader)PC/ECwrites stop if the leader is unreachable; failover is a availability gap
etcd, ZooKeeper, ConsulPC/ECmajority quorum or no writes — correctness is the whole point
Cassandra, DynamoDB (tunable)PA/ELstays writable under partition; you dial C up per query with quorums
MongoDB (default)PC/ECprimary-only writes; w:majority makes the C explicit
DNSPA/ELthe canonical AP system — TTL is the staleness budget
  • 'CA' is a category error: a single-node database is trivially CA because it has no partitions to survive — the moment you replicate across a network, P is imposed on you. Saying 'we chose CA' tells an interviewer you haven't thought about failure.
  • Availability in CAP is absolute, not a percentage: it means every non-failing node answers. A system that returns errors from a minority partition is 'unavailable' in CAP terms while still being 99.99% available in SLO terms. The theorem is a proof, not an ops metric — don't conflate them.
  • The choice is per-operation, not per-system: the same product can take payments through a CP path (a linearizable ledger) and serve the product catalogue through an AP path (a stale-tolerant cache). Senior answers assign consistency levels to operations, not to databases.
  • PACELC's 'else' branch is where you actually live: partitions are rare; cross-region round-trips are constant. Choosing w:majority across three regions costs you ~100ms on every write with no partition in sight — that latency, not the theorem, is what shapes most designs.

🔄 Likely follow-up questions

  • Why is 'CA' impossible for any replicated system?
  • Your service spans three regions with w:majority — what's the write latency floor and why?
  • Which of your endpoints could safely be AP, and how would you prove staleness is acceptable?