CAP says you must choose between consistency and availability under a network partition. What are you giving up, concretely?

The C in CAP is linearisability

CAP's consistency is linearisability: every read observes the most recent completed write, and the system behaves as though there is one copy of the data serving operations in real-time order. It is a recency guarantee about a single object. Gilbert and Lynch's 2002 proof pins availability equally precisely, as every request to a non-failing node returning a non-error response, and partition tolerance as the network being permitted to drop arbitrarily many messages between nodes.

None of that is ACID's C. ACID consistency means the database does not commit a state violating its declared invariants: foreign keys hold, a CHECK constraint is not breached, the sum of the two account balances in a transfer is unchanged. That is a property of a transaction against integrity rules on one node, and a single unreplicated PostgreSQL instance provides it while providing nothing at all about replication. Serialisability is a third thing again: it says a set of concurrent multi-object transactions produces some result equivalent to running them one at a time, but it makes no promise that the equivalent order matches wall-clock order, so a serialisable system can legally serve you a stale snapshot. Candidates who use these three interchangeably signal that they have memorised a triangle rather than reasoned about a system.

What breaks when the link goes down

Take an inventory service replicated across two datacentres, Mumbai and Singapore, holding the stock count for a product with three units left. The link between them fails. Both sides are up, both are serving traffic, neither can hear the other.

Choose consistency and the system must stop accepting writes on at least one side. In a quorum system this happens by construction: with replicas split two against one, the minority side cannot assemble a majority and so cannot elect a leader or commit anything. Customers routed there see errors or timeouts on add-to-cart. You have given up availability for those users, for as long as the partition lasts, and the compensation is that nobody oversells.

Choose availability and both sides keep selling. Mumbai sells two units, Singapore sells two units, and both believe they were within stock. When the link heals you have divergent replicas and a business problem that no database can resolve for you, because the correct answer requires knowing whether you would rather cancel an order or hold a backorder. This is the part that gets glossed over: choosing availability does not remove the work, it relocates it into your reconciliation logic and your customer-service process. Last-write-wins is not conflict resolution, it is a decision to discard one of the two sales silently.

The choice binds only while the partition exists

CAP describes what a system must sacrifice during a partition, not what it is forever. Brewer made this point explicitly in his 2012 retrospective on the theorem: "pick two of three" is misleading, because partition tolerance is not something you elect. Packets get dropped whether you approve or not, so the real statement is that when a partition occurs you must sacrifice linearisability or availability, and outside that window you may have both.

A system can also make the choice per operation rather than per cluster. In Cassandra, R + W > RF guarantees that read and write quorums overlap, so the level is a property of the query rather than of the deployment.

-- Same table, two different trade-offs, chosen per statement in cqlsh.
CONSISTENCY QUORUM;       -- majority across all DCs: survives a DC loss, pays the WAN round trip
SELECT stock FROM inventory WHERE sku = 'X1';

CONSISTENCY LOCAL_QUORUM; -- majority within the local DC only: fast, but can serve a stale count
SELECT stock FROM inventory WHERE sku = 'X1';

Where the answer should actually land: PACELC's else-branch

Partitions are rare and brief. The trade-off you make every millisecond of every normal day is the one CAP does not describe, and this is the distinction that separates a strong answer. Abadi's PACELC formulation states it: if there is a Partition, choose Availability or Consistency; else, choose Latency or Consistency.

Look again at the two statements above with the network perfectly healthy. LOCAL_QUORUM answers in single-digit milliseconds and may return a count another region has already decremented. QUORUM waits for a cross-region round trip, so a Mumbai-to-Singapore acknowledgement costs you tens of milliseconds of user-visible latency on every single request. Nothing is broken. You are simply paying for recency, continuously, in a currency your product manager cares about. In Abadi's classification Dynamo-derived stores such as Cassandra and Riak are PA/EL, while systems built on synchronous consensus are PC/EC: they reject writes on a minority partition and pay the coordination latency the rest of the time.

Interviewers ask this question because a candidate who only knows CAP will design for a failure mode that occupies a vanishing fraction of the system's life, and will silently accept WAN latency on the read path without ever recognising it as a decision. The good answer names the partition behaviour, then immediately moves to what the system does when nothing is wrong.

Say linearisability, not consistency, and scope it to the partition window. Then spend most of your answer on the else-branch, because that is where the system lives and where the latency your users feel is being spent.