CAP Theorem

CAP describes a distributed system's constrained choices during a network partition: it cannot guarantee both strong consistency and availability for every request. The practical decision is how affected operations behave when replicas cannot coordinate.

The CAP theorem describes a limit on distributed data systems when a network partition occurs. A partition means communication between parts of the system is disrupted or delayed enough that they cannot reliably coordinate. CAP names three properties: consistency, availability, and partition tolerance.

In the usual CAP formulation, consistency means each successful read observes the latest completed write, as if operations happened atomically in one global order. Availability means every request received by a non-failing node eventually gets a response. During a partition, a system cannot guarantee both of these properties for all requests: it must reject or delay some operations, or respond despite the risk of stale or conflicting data.

Partition tolerance is not usually a convenient feature to switch off in a distributed system. Networks can fail, and a system designed to span machines must have some behavior when they cannot communicate. The practical design choice is therefore often whether to favor consistency or availability for affected operations during a partition.

This does not mean a system is permanently either “CP” or “AP” in every situation. Different operations, data, or failure modes may have different guarantees, and outside a partition a system may provide both timely responses and strong consistency. Clarify the consistency model and the conditions under which availability is promised rather than relying on the labels alone.

Key points

• CAP describes a constraint during network partitions, not a universal choice among three independently selectable features.
• Strong CAP consistency is commonly interpreted as linearizability: operations appear atomic and globally ordered.
• CAP availability requires responses from non-failing nodes; it does not guarantee that returned data is fresh.
• Partition tolerance addresses communication failures between system components.
• Choose behavior per operation and data rather than relying only on CP/AP labels.

Interview questions

Explain the CAP theorem and what trade-off it describes.

CAP stands for consistency, availability, and partition tolerance. In the classic formulation, consistency means operations behave as though they occurred in a single atomic order, while availability means each request to a non-failing node gets a response. When a partition prevents nodes from coordinating, a system cannot guarantee both properties for every request. It must sometimes refuse or delay requests, or answer without guaranteeing the latest value.

What can happen to reads and writes when a network partition separates replicas?

If two nodes cannot communicate, one may accept a write while the other cannot learn about it. A read served by the second node could therefore miss the latest write. To preserve a strong consistency guarantee, the system may refuse or wait on operations that cannot be safely coordinated; to keep responding, it may return data that is stale or later require conflict resolution. The appropriate choice depends on the operation's correctness requirements.

Why is partition tolerance not simply a setting that a system can disable?

No. A partition is a network communication failure, not a normal operating condition that a distributed design can safely assume will never occur. The useful question is what the system does when coordination is unavailable. CAP helps describe this constrained case, while reliability engineering also examines how often failures occur and how quickly service recovers.

How does CAP availability differ from service uptime?

CAP's availability is a per-request property: each request reaching a non-failing node must receive a response. That response may contain old data, so availability does not imply freshness or correctness under every application rule. Uptime is generally an aggregate operational measure, such as the fraction of time a service is reachable. A system can have high uptime while still rejecting certain operations during partitions to preserve consistency.

Why can the CP/AP labels be misleading when evaluating a database?

The labels are shorthand, not complete descriptions of a product's behavior. A useful evaluation asks which operations are allowed during a partition, whether reads can be stale, how writes are ordered, and what happens to concurrent updates. Guarantees can differ by data item or operation, and strong consistency outside partitions does not by itself determine behavior during one. Ask for the concrete consistency model and failure policy.