CAP TheoremDistributed SystemsConsistencyAvailabilitymiddle level

CAP Is a Partition-Time Trade-off

the question

What is the CAP theorem, and what does it mean in practice when you design a distributed system?

what they're testing: The interviewer is testing whether you can turn a formal failure constraint into sensible consistency and availability choices for real operations.

a strong answer

CAP says a partition-tolerant replicated service cannot guarantee both linearizable behavior and a non-error response to every request that reaches a non-failing node. The conflict matters when lost or delayed communication splits replicas. It is not a standing rule that a database simply "picks two."

To preserve consistency during a partition, the service must reject, delay, or stop operations that cannot be coordinated. A leader or majority side may continue serving. To preserve CAP availability, every non-failing node must answer requests, which can expose stale values or accept conflicting updates that need reconciliation.

In practice, decide by operation and invariant, not by branding a whole product CP or AP. Unique ownership and balance changes often need coordination; counters or feeds may tolerate temporary divergence. Topology, quorum rules, read and write settings, leader behavior, and conflict handling determine what clients see. CAP does not by itself describe latency, durability, transaction scope, or measured uptime. A system can give up CAP's absolute availability guarantee during rare partitions and still be highly available in normal operation.

Where people slip

the tempting wrong answer, and what's actually true

CAP means a distributed system always picks any two of consistency, availability, and partition tolerance.
CAP does not grant any two properties. When partitions must be tolerated, a service cannot guarantee both linearizability and CAP availability, and it may guarantee neither.
Consistency in CAP is the same as the C in ACID.
They are different. CAP's consistency model is atomic consistency, commonly called linearizability: operations appear to occur on one copy in an order that respects real time.
A system is CAP-available if at least one replica can still serve traffic.
Serving from one replica is not enough. CAP availability requires every request received by every non-failing node to eventually get a non-error response.
Choosing consistency during a partition means the whole application must go offline.
The whole application need not go offline. A quorum-based service can continue on the majority side while operations on the minority side fail or wait.

If they push further

When would you choose consistency over availability?

Tie the choice to an invariant: operations such as unique ownership or balance updates should fail rather than accept conflicting state, while less critical derived data can often reconcile later.

Can a CP system still be highly available in practice?

Yes. CAP availability is an absolute guarantee, so a system can forfeit it in rare partitions while still delivering excellent measured uptime and serving requests through a reachable majority.

Is a database simply CP or AP?

Usually that label is too broad; discuss the operation, topology, read and write settings, and exact partition because one product can expose different guarantees for different paths.

Sources

Now answer it yourself.

Reading a strong answer is easy. Producing one under pressure is the skill the interview tests. Gapmap grades your answer against the same bar an interviewer would.

was this useful?

beta

The interviewer part is in the works.

The diagnostic, personal maps, and AI mock interviews are being finished right now. The notes stay free either way. Leave an email and you'll get the first-cohort invite, plus a month of Pro when it opens.