# CAP and PACELC: Thinking More Clearly About Consistency

DevFeed: [CAP and PACELC: Thinking More Clearly About Consistency](<https://devfeed.tech/articles/cap-and-pacelc-thinking-more-clearly-about-consistency-12460.md>)

Original publisher: [Read original article](<http://brooker.co.za/blog/2014/07/16/pacelc.html>)

Author: Marc Brooker

Published: 2014-07-16T00:00:00Z

Content type: article

Language: en

Sources: [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog.md>), [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog-2.md>)

Topics: [distributed-systems](<https://devfeed.tech/topics/distributed-systems.md>), [Latency](<https://devfeed.tech/topics/latency.md>), [Database](<https://devfeed.tech/topics/database.md>), [Availability](<https://devfeed.tech/topics/availability.md>)

Tags: [availability](<https://devfeed.tech/tags/availability.md>), [database](<https://devfeed.tech/tags/database.md>), [distributed-systems](<https://devfeed.tech/tags/distributed-systems.md>), [latency](<https://devfeed.tech/tags/latency.md>)

## AI overview

This article explains how PACELC extends CAP as a way to reason more completely about consistency tradeoffs in distributed database systems. During network partitions, it considers the tradeoff between availability and consistency; during normal operation, it considers the tradeoff between latency and consistency. The article presents PACELC as a clearer teaching tool while acknowledging that it is not ideal and that CAP remains useful.

## Source excerpt

CAP and PACELC: Thinking More Clearly About Consistency CAP is confusing. PACELC is better, but still not ideal. In some sense, the CAP theorem has been too successful. With its snappy name and apparently easy-to-understand behavior, CAP has become the go-to way of talking about tradeoffs in distributed systems. Despite its apparent simplicity, confusion, misunderstandings, misrepresentations and debates about CAP are widespread. Criticism of CAP is also widespread, both in its use as a teaching tool and as a way of reasoning about tradeoffs. Dan Weinreb, Henry Robinson, and Michael Stonebraker have written good examples of the genre. It would be great to find a tool for teaching, and learning about, these tradeoffs that doesn't have the same shortcomings as CAP. In this post, my focus is on CAP as a tool for learning and teaching about distributed systems tradeoffs, rather than its use by experienced practitioners. The problems with CAP as a teaching tool, as I see them, are: The popular belief is that CAP means pick any two. The confusion is about the existence of CA systems, which pretend that partition tolerance is optional, or claim that partitions don't happen. Marketing from database vendors plays into this, too. In reality, you can't sacrifice partition tolerance, because partitions happen in real large-scale systems all the time. There is some evidence that the popularity of this misconception is waning, but it would be premature to announce its death. The second misconception is that the CAP theorem means you can't be consistent and available during partitions. That's not true, at least in the case of Gilbert and Lynch's version of the theorem. Specifically, the CAP theorem only prevents everybody from being consistent and available, not anybody (some literature calls this always available). It doesn't prevent clients and replicas on the majority side of simple partitions from making progress, and experiencing both consistency and availability. There are o