CAP theorem is frequently criticized by distributed-systems researchers as too coarse a model to directly drive real architecture decisions. What are the main limitations of the CAP formulation itself, and in what way does PACELC address one of them while still leaving others unresolved?

## Where the crispness comes from CAP theorem earned its influence because it gave the industry a crisp, provable statement to reason with, but that crispness comes from deliberately simplifying real systems down to a small number of binary labels, and understanding exactly where that simplification breaks down is what separates using CAP as a slogan from using it as an actual design tool. ## Binary labels for a whole system The first and most cited limitation is that CAP treats Consistency and Availability as single, all-or-nothing properties of an entire system, when in practice both are spectrums that vary by operation, by table, and even by individual field. A real system rarely offers consistency as one monolithic guarantee; it offers a range of possible guarantees from strict, always-latest correctness down through weaker guarantees, and a mature deployment typically applies different points on that spectrum to different data based on need, as shown by databases that expose a tunable consistency level per query. ## Availability with no clock on it Similarly, 'availability' in Gilbert and Lynch's original formalization means every request to a non-failed node eventually receives a response, with no bound on how long 'eventually' takes. That technical definition is almost useless for practitioners, who care about availability within a latency budget — a response in 50ms counts, a response in 50 seconds effectively doesn't for most user-facing purposes. A system can be 'available' by the formal CAP definition while being completely unusable in production because every request takes ten seconds, a gap the formal theorem doesn't address at all. ## What PACELC closes This is exactly the gap PACELC was designed to close, but only partially. Daniel Abadi's insight was that CAP is entirely silent about system behavior when there's no partition, which, for almost every real deployment, is nearly all the time, and that even in that unpartitioned state, systems still make a real, continuous trade-off between latency and consistency, because achieving strong consistency requires coordination round-trips that cost time regardless of network health. By adding the 'else, Latency or Consistency' clause, PACELC gives architects vocabulary for the decision that actually dominates day-to-day system behavior, rather than only the rare partition-time decision CAP describes. This is a genuine improvement: it lets you describe a system as, for example, consistency-favoring during a partition but latency-favoring otherwise, a combination CAP alone has no way to express, since CAP has nothing to say once the partition ends. ## What it inherits anyway But PACELC inherits CAP's other core limitation: - it still models each axis as a single letter choice rather than a graded spectrum; - it still describes the system as a whole rather than the operation. A real deployment, as with per-request consistency-level knobs, might run some queries at a strongly consistent, higher-latency setting and others at a weakly consistent, low-latency setting simultaneously — a single system-wide label can't represent a system doing both at once for different data. Some researchers have proposed richer frameworks to address this — for instance, treating consistency as a continuous dial, how stale can a read be in time or in number of missed updates, rather than a binary, or reasoning about availability in terms of the fraction of requests served within a latency budget rather than a yes/no property — but none has achieved anything like CAP's ubiquity as shared vocabulary, partly because they trade CAP's clean, quotable, provable statement for something more accurate but much harder to state simply. ## Real partitions are messier than the model A further, more subtle limitation, pointed out by later critics including Brewer himself in a 2012 retrospective, is that CAP's 'pick two of three' framing invites false precision: real partitions aren't a single global event affecting the whole system uniformly. A partition might affect only some node pairs, might be partial with packets dropped but not all of them, and might be asymmetric where node A can reach node B but not vice versa. CAP's clean binary model treats 'partitioned' as a single global boolean state, when production partitions are messier, and a system's actual behavior under a partial or asymmetric partition can differ meaningfully from its behavior under the clean, total partition CAP's proof assumes. ## The practical upshot The practical upshot for someone operating at a principal level is that CAP and PACELC remain genuinely valuable as shared vocabulary for framing a trade-off discussion quickly with a team or in a design doc, and as a sanity check against claims like 'CA' that reveal a team hasn't thought the problem through — but neither should be treated as a complete specification for a real system's behavior. Real architecture work requires going a level deeper: - naming the actual consistency guarantee needed per operation; - the actual latency budget that counts as 'available' for that operation; - and how the system behaves under partial and asymmetric partitions specifically. None of which the two-letter or four-letter labels capture on their own.