Concepts
CAP theorem trade-offs
Intuition
Imagine two branches of a bank in different cities, each with its own copy of the customers' balances, connected by a phone cable that sometimes goes down. While the cable works, the two branches can notify each other of any deposit and always stay in agreement. But if the cable goes down right when one customer deposits money at one branch and another customer asks for the balance at the other, the branch that received the question has only two options: answer with the old number (which may be wrong) or say 'I don't know, wait for the cable to come back' (leaving the customer without an answer). It cannot do both at the same time, and this forced choice, at the moment communication fails, is exactly what the CAP theorem describes.
How it works
Gilbert and Lynch formalize the three properties in an asynchronous model: Consistency requires that every read, after a completed write, returns that value or a more recent one, as if there were a single logical copy of the data; Availability requires that every request to a non-failing node eventually receives a response; Partition tolerance means the system keeps operating even when messages between subsets of nodes are lost or arbitrarily delayed, with no one knowing whether the message vanished or is just slow. The proof uses two nodes replicating the same data, separated by a partition: one client writes to the first node, which responds (availability) without being able to propagate the update; another client reads from the second node, which is also required to respond (availability) but only has the old value — breaking consistency. The central point is not that 'you pick 2 out of 3 forever', but that this choice is only forced at the moment a partition actually happens: each isolated node must decide, right there, between responding with possibly stale data or refusing to respond until it is sure. Outside an ongoing partition, nothing prevents the system from being consistent and available at the same time — and in a partially synchronous model with timeouts, the system still faces the same theorem, but can manage the trade-off in a more informed way, tolerating inconsistency only for the estimated duration of the partition.
In practice
Distributed databases explicitly declare their side of the trade-off only for the partition case: systems such as classic DynamoDB or Cassandra choose availability (AP) and accept potentially stale reads, while systems with strong consensus such as relational databases with synchronous replication choose consistency (CP) and refuse to answer when they cannot confirm a quorum. The PACELC extension (Abadi) is a reminder that even with no partition at all, the same system still chooses between latency and consistency — which is why architects evaluate CAP as a decision about behavior during network failures, not as a permanent label for the whole system.
Use it in a design
Practice the cases that rely on this concept in the System Design school.