CAP theorem
CAP describes the guarantees a distributed data system can provide during a network partition. It names three properties:
- Consistency: every read returns the most recent write or an error.
- Availability: every request receives a response, without a promise that it contains the newest value.
- Partition tolerance: the system continues operating despite messages being lost or delayed between nodes.
Networks fail, so a practical distributed system must tolerate partitions. During the partition, the design chooses whether to preserve consistency or availability. CAP does not say that a system permanently chooses only two properties. It describes the choice made while communication is broken.
- Partition
Messages between replicas may be lost or delayed.
- Consistency choice
Wait for the required coordination or return an error when it cannot complete.
- Availability choice
Serve from a reachable replica, accepting that its value may be stale.
- Recovery
Reconcile according to the data model when communication returns. CAP is about behavior during the partition.
During a partition, a system cannot guarantee both linearizable consistency and a response to every request.
How to read this model
Two replica holders with a disconnected communication bridge. The object is a teaching analogy. Inspecting a part highlights its role; it does not execute or simulate the software. Cabinet trays are records, workpieces are data, and latches are checks. Unless an explanation states a quantity, compartments and sample workpieces do not denote data counts. Part dimensions are not a quantitative scale.
Concept redrawn from CAP theorem revisited.
CP: consistency and partition tolerance
A CP design waits for the required nodes to respond. If the partition prevents that response, the operation returns a timeout or another error. CP fits data where accepting a stale or conflicting value would be worse than refusing the operation, such as an inventory reservation or a transaction.
AP: availability and partition tolerance
An AP design returns the best value available on a reachable node. That value may be stale. When communication returns, replicas propagate writes and reconcile state. AP fits systems that must keep serving during dependency failures and can explain or tolerate eventual consistency.
CAP is a constraint on one failure mode, not a complete database-selection rule. Define the business invariant first, then choose the guarantee for each operation. Databases and availability patterns apply this choice to storage and traffic.