Recommended Free Tools
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 tradeoff a distributed data system faces when a network partition prevents some of its nodes from communicating: it cannot guarantee both strict consistency and availability for every request. The choice is about what the system does during that failure—not a permanent label saying a database simply “has” two of the three properties.
What CAP means
CAP stands for consistency, availability, and partition tolerance. In the theorem’s operational sense, these terms have specific meanings:
- Consistency: A read returns the most recent completed write, or the system returns an error if it cannot guarantee that result. This is stronger than replicas eventually converging. AWS’s CAP explanation uses this latest-write-or-error definition.
- Availability: Every request to a node receives a non-error response. Returning an error, or leaving a request unanswered, does not satisfy CAP availability—even if most of the system remains usable.
- Partition tolerance: The system continues to operate despite messages being lost between nodes. A partition is a communication failure that splits nodes into groups that cannot reliably exchange messages.
These definitions explain why the familiar “choose two of three” phrase can mislead. In a real distributed deployment, network partitions cannot simply be ruled out while retaining a meaningful guarantee that the system will withstand them. The practical question is what requests the system allows to proceed on each side of a partition. AWS summarizes the consequence: a system that favors availability may return potentially inconsistent data; one that favors consistency may return an error rather than violate its consistency guarantee.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallWhat happens during a partition
Imagine replicas on two sides of a broken network link. If both sides accept writes, they may each acknowledge a different latest value. A read from one side can then fail to reflect a write acknowledged on the other. That response may preserve availability, but it cannot provide the strict latest-write consistency defined by CAP.
#1 Best Overall
A system that prioritizes consistency can instead refuse requests that it cannot safely coordinate. Some nodes or clients may receive errors or be unable to commit writes until communication is restored or a safe majority is available. That sacrifices CAP availability for those requests, while protecting the consistency guarantee.
These are choices about individual requests, nodes, and operations—not necessarily a complete outage versus uninterrupted service. The exact outcome depends on which nodes can communicate, which replicas a request needs, and what guarantee that operation requires.
CAP availability is stricter than ordinary uptime
In everyday product discussions, “available” often means that a service is up for most users or meets its service-level objective. CAP availability is narrower and more demanding: every node must be able to answer reads and writes, including nodes isolated by a partition. A service can continue serving many clients and still fail this strict CAP definition if requests to nodes on a minority or isolated side cannot proceed.
Rank #2
For that reason, a claim that a database is “available” should clarify which clients, nodes, and operations it covers. FoundationDB’s documentation explicitly distinguishes its partition-time CAP definition from the looser sense of high availability commonly used to describe a service.
How database behavior depends on operations and configuration
Apache Cassandra: tunable consistency
Apache Cassandra 5.0 documentation describes Cassandra as prioritizing availability and partition tolerance, while relaxing consistency to some extent. It also describes eventual consistency for writes to a single table: replicas can temporarily disagree and converge later. But that is not the whole story. Cassandra supports lightweight transactions with linearizable consistency, so the guarantee can differ by operation.
Cassandra’s Dynamo architecture documentation explains that data is replicated across nodes and data centers, with replication strategy and consistency levels configurable. A read or write consistency level determines how many replicas must participate. When enough replicas participate, quorum intersection can ensure that a subsequent read sees a write. The selected level therefore affects both the consistency a request can obtain and whether it can succeed when replicas are unreachable.
Rank #3
In practice, do not infer the behavior of every Cassandra operation from a single AP label. Check the consistency level used by the operation, the replication configuration, and which replicas can respond.
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 problemsFoundationDB: majority coordination
FoundationDB 8.0.0 documentation describes a different partition-time choice: consistency is favored over availability for affected machines. Its coordination servers use a majority to determine which partition can proceed. In the documented example with three machines, the two that can communicate may continue, while the isolated machine cannot commit new transactions. A client connected only to that isolated machine may see the database as down.
This is FoundationDB’s documented design and example, not an independent benchmark. It also shows why a system may remain useful to clients on one side while being unavailable, in the strict CAP sense, to nodes or clients on another.
Rank #4
How to compare CAP claims
Labels such as “AP” and “CP” can be shorthand, but they hide details that matter when choosing or configuring a database. Compare documented behavior along these axes:
- Partition behavior: What happens to reads and writes on each side of a partition?
- Consistency model: Is the guarantee linearizable, eventual, or another model? Does it apply to every operation or only selected ones?
- Coordination threshold: How many replicas or coordination members must respond for an operation to proceed?
- Minority-side behavior: Can clients connected only to an isolated or minority partition read, write, or commit transactions?
- Request tradeoff: How does the chosen consistency level affect the chance that a request succeeds when replicas are unreachable?
Those questions describe actual system behavior more usefully than assigning one unconditional CAP category to an entire product.
Where the theorem came from
Eric Brewer introduced the CAP conjecture in 2000. Seth Gilbert and Nancy Lynch proved it in 2002. Their later review, Perspectives on the CAP Theorem, appeared in Computer 45, no. 2, in February 2012, pages 30–36. The MIT Open Scholarship record identifies the review and its publication details.
Quick 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.
