iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
The CAP theorem describes a specific choice a distributed data store faces when a network partition prevents nodes from communicating: protect consistency by refusing or failing some requests, or keep answering requests even though some answers may be stale or divergent. It is not a general rule that every system must permanently sacrifice one of three desirable qualities.
What is the CAP theorem?
The CAP theorem is a result about the guarantees a distributed data store can provide when a network partition occurs. If replicas cannot exchange messages because the network drops or delays them, a system designed to keep operating through that failure cannot guarantee both that every request receives a response and that every read returns the latest write.
The theorem is associated with an idea Eric Brewer introduced in 2000 and its formalization by Seth Gilbert and Nancy Lynch in a 2002 paper. Gilbert and Lynch revisited the subject in “Perspectives on the CAP Theorem,” published in IEEE Computer 45, no. 2, in February 2012. MIT Open Scholarship’s record provides the paper’s publication details and abstract; AWS’s CAP theorem documentation also cites the formal result.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →What do C, A, and P stand for?
- Consistency (C): In the CAP formulation, a read returns the most recent write, or the system returns an error rather than an older value.
- Availability (A): Every request receives a response. That response is not necessarily based on the latest write.
- Partition tolerance (P): The system continues operating despite dropped or delayed messages between nodes.
These terms have specific meanings here. In particular, CAP consistency is a guarantee about the ordering and visibility of reads and writes, not a synonym for data correctness in every broader sense. Availability means a response, not necessarily a successful response containing fresh data.
#1 Best Overall
Does CAP mean you can only choose two?
Not as a permanent, across-the-board menu. The forced choice is about behavior during a network partition. A system that must tolerate partitions cannot, at the same time, ensure both that every request is answered and that every read reflects the latest write. It can reject or fail operations when it cannot establish that a read is current, or continue responding while allowing stale or divergent data.
Partition tolerance is not usually a casual optional feature for a multi-node service expected to survive communication failures. The practical design question is therefore: when replicas cannot communicate, which requests should still receive an answer, and what freshness guarantee can the application accept? CAP is not a general ranking of database quality, nor does it say a database permanently lacks one of C, A, or P under normal conditions.
What does the trade-off look like in practice?
Imagine two replicas, one of which receives a write while a partition prevents it from telling the other replica. A client then asks the isolated replica to read that value. If the system cannot verify that the replica has the latest state, it has two broad options:
Recommended Free Tools
- Protect consistency: Refuse or fail the read rather than risk returning an older value. This sacrifices availability for that request under the partition.
- Keep responding: Return the value the replica has. The request receives a response, but the result might be stale or later conflict with another replica’s state.
Which behavior is appropriate depends on the operation and the application’s requirements. A request that must not act on outdated account or inventory data may warrant failing closed; a read where temporary staleness is acceptable may be allowed to complete. CAP describes the constraint behind that decision, not a single setting that determines every behavior of a product.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How Cassandra illustrates configurable consistency
Apache Cassandra’s documentation shows why a whole database should not be assigned one unconditional CAP label. The Cassandra 5.0 Guarantees page describes Cassandra as prioritizing availability and partition tolerance, while also describing eventual consistency for writes to a single table and support for lightweight transactions with linearizable consistency. The guarantees differ by operation and feature.
Cassandra also exposes consistency levels that determine the minimum number of replicas that must acknowledge a read or write for it to succeed. In the Apache Cassandra Basics guide’s example, a three-replica setup using QUORUM requires acknowledgements from two replicas.
That quorum example explains acknowledgement behavior; it does not prove that choosing a quorum removes the CAP trade-off under every failure or deployment condition. When evaluating a real system, examine what happens during a partition, whether reads can be stale, which requests may fail to protect consistency, and which operations or settings receive each guarantee. Always check the product version and configuration scope: the cited guarantees page identifies itself as Cassandra 5.0.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsQuick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
