tezvyn:

CAP theorem and real database tradeoffs

AI-drafted, machine-checkedSource: interviewadvanced
WHAT IT TESTS

CAP as a partition-time choice.

OUTLINE

during a partition you pick consistency or availability, CP systems reject requests, AP systems stay available but stale.

RED FLAG

thinking you pick two of three at all times.

WHAT THIS TESTS The interviewer checks whether you understand CAP correctly rather than reciting the pick-two slogan. The subtlety is that the theorem only bites during a network partition.

A GOOD ANSWER COVERS CAP says a distributed system cannot simultaneously guarantee consistency, availability, and partition tolerance. Because network partitions are unavoidable in real distributed systems, partition tolerance is not optional; the genuine decision is what you do during a partition. A CP system prioritizes consistency: when nodes cannot communicate, it refuses or blocks requests it cannot serve correctly, sacrificing availability. A single-primary RDBMS behaves this way, since a partitioned-off replica cannot accept writes. An AP system prioritizes availability: Cassandra keeps accepting reads and writes on whichever nodes are reachable, so clients always get a response, but the data may be stale until the partition heals and replicas reconcile. Spanner and CockroachDB do not escape CAP; they engineer highly reliable networks and use consensus, so partitions are rare and during one they behave as CP, favoring consistency over availability.

COMMON WRONG ANSWERS Saying you statically choose two of three properties at all times; the tradeoff is only forced during a partition. Claiming Spanner achieves all three and beats the theorem. Confusing CAP consistency with ACID consistency.

LIKELY FOLLOW-UPS How does PACELC extend CAP to latency when there is no partition? How does tunable consistency in Cassandra let you slide along the spectrum? How does Spanner use TrueTime? What is the difference between CAP consistency and ACID consistency?

ONE CONCRETE EXAMPLE A datacenter link drops. The RDBMS replica on the far side, being CP, stops accepting writes so no conflicting state is created and availability suffers. A Cassandra ring spanning both sides, being AP, keeps serving reads and writes with a low quorum, so users stay served but two sides may briefly diverge and reconcile later. A Spanner deployment, having rare partitions and consensus, refuses minority-side writes to preserve consistency, behaving as CP during the event.

Read the original → en.wikipedia.org

Get five bites like this every day.

Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.