CAP’s Hard Boundaries: A Closer Look at the “You Do It Too” Argument
Partition tolerance is often treated as a menu option—pick consistency, pick availability, or pick some comfortable middle ground. But the formal results behind the CAP theorem do not leave that kind of wiggle room. In response to the claim that partition intolerance simply means “partitions are not supported” and that such systems can reasonably be labeled CA, it’s worth revisiting what the theorem actually forces.
Why the Categories Don’t Overlap
If a system is partition-intolerant, it cannot maintain its invariants when a partition does occur. The Gilbert & Lynch proof is specific about the tradeoff: during a partition, such a system must either allow nonlinearizable histories or leave some requests to non-failing nodes unanswered. Stronger still, proof results extend this to sequential consistency, serializability, repeatable read, cursor stability, and snapshot isolation—all forfeited if a system preserves availability across a partition.
This is why the suggestion that CP and AP share an overlap is mathematically unfounded. CP means both consistency and partition tolerance; AP means both availability and partition tolerance. An overlap between the two would imply a system that is simultaneously consistent, available, and partition-tolerant—the very thing the CAP theorem rules out. Asserting that overlap exists is tantamount to asserting the theorem is false.
Labels That Mislead
The suggestion that CA systems and CP systems are often distinct only in practice misses the point. If the theorem holds, every CA system fails to be CP and every CP system fails to be CA—there is no partial credit here. Either a system satisfies the formally defined properties, or it does not. If it does not, the onus is on providing a counterexample, not a looser definition.
This matters when systems that “stop working during the partition” are classified as CA. Gilbert & Lynch define availability plainly: every request received by a non-failing node must produce a response. A system that halts its operations during a partition is failing to meet that bar—it is not “consistent and available once things settle.” It is simply unavailable when it matters. Calling that CA papers over the actual behavior under fault.
Faults Are Not Neatly Isolated
The argument that node crashes, process failures, and network partitions can each be handled with independent priorities sounds orderly, but the real-world lines are blurrier. In the formal model behind the CAP proof, “the network” is everything that passes messages between processes. Real processes do not behave like the idealized models: they are not single-threaded, they do not execute in bounded time, and they can delay messages arbitrarily. Garbage collection pauses, for example, are a classic source of “network” partitions—the node is still alive, but its messages are not moving.
This is not an academic quibble. Attempting to isolate network partitions as a special fault class, separate from other failures, is likely why many databases fail Jepsen-style tests. Designing an algorithm that is safe under the general case of an asynchronous network is more tractable than trying to impose synchronous behavior through imperfect failure detectors and special-casing.
Nor is partition frequency a reasonable excuse to skip the problem. LANs see partitions all the time, and even clusters with as few as two nodes connected by redundant physical switches have experienced them. The data contradicts any assumption that smaller deployments are naturally shielded from this fault class.
