CAP Theorem Explained for Beginners

Two locations hold copies of a value. A network problem prevents them from communicating. A customer reaches one location while another customer updates the value at the other. The locations cannot simply assume they both know the latest result.

CAP describes a limit for distributed shared data under network partitions: you cannot guarantee both its strong consistency property and its availability property for all requests in that situation. It is more precise than a general slogan to “pick any two” in normal operation.

In this discussion, consistency means linearizability: operations behave as if applied to one current copy in an order respecting completed operations. It is not merely valid data types or the “C” in ACID transactions.

Availability in CAP requires requests to non-failing nodes to eventually receive a result rather than being refused because another node is unreachable. This formal property is different from a monthly availability percentage or a response-time objective.

A partition is a loss or delay of communication between parts of the system. If the system relies on that communication, it needs defined behaviour for the affected operations. Normal operation still involves latency, cost and consistency choices outside the theorem’s narrow impossibility result.

Location A starts with value 1, and B has a copy of 1. Disconnect the link, then commit value 2 at A. In this deliberately asymmetric model, A is the authorised writer. B either refuses the isolated read or answers from its local older value, depending on the selected policy.

Refusing B’s read sacrifices availability for that read; returning 1 after A’s write completed does not provide the strong single-copy behaviour described here. Reconnecting immediately copies A to B in this toy model. Real systems need protocols for quorum, recovery and conflicts; this demonstration is not a database implementation.

A product catalogue display may tolerate an older description for a while. Allocating the last available item or reserving a unique booking slot may need a different rule, such as refusing an isolated write or requiring an authoritative participant.

If disconnected sides both accept competing writes, reconnecting needs conflict rules. Last-writer-wins can discard an update; timestamps can be difficult to compare across machines. The acceptable behaviour depends on what the value means.

Do not treat a database brand as one permanent CAP label. Settings, operations, topology and failure conditions affect guarantees. Read the selected product’s actual consistency, read and write contracts.

The Gilbert and Lynch paper formalises the partition scenario and guarantees. The lab illustrates one consequence; it does not reproduce the proof. Source checked 6 October 2026.

When evaluating a service, ask what completes during a partition, which reads can be stale and what happens after communication returns. Test the configured operation with an explicit failure and observation boundary.

Compare latency and operating cost too. Blocking an operation may preserve an important rule while making the user wait or retry. Returning quickly is useful only if the result’s semantics are acceptable.

CAP concerns specific guarantees during partitions. Define the affected operation and decide what an isolated location may promise.

Use precise meanings, inspect actual product contracts and plan reconciliation. An uptime percentage and a CAP availability property answer different questions.