# Let's Consign CAP to the Cabinet of Curiosities

DevFeed: [Let's Consign CAP to the Cabinet of Curiosities](<https://devfeed.tech/articles/let-s-consign-cap-to-the-cabinet-of-curiosities-12559.md>)

Original publisher: [Read original article](<http://brooker.co.za/blog/2024/07/25/cap-again.html>)

Author: Marc Brooker

Published: 2024-07-25T00:00:00Z

Content type: opinion

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>), [Availability](<https://devfeed.tech/topics/availability.md>), [Cloud](<https://devfeed.tech/topics/cloud.md>), [Internet of things](<https://devfeed.tech/topics/iot.md>)

Tags: [availability](<https://devfeed.tech/tags/availability.md>), [cloud](<https://devfeed.tech/tags/cloud.md>), [distributed-systems](<https://devfeed.tech/tags/distributed-systems.md>), [dns](<https://devfeed.tech/tags/dns.md>), [iot](<https://devfeed.tech/tags/iot.md>), [load-balancer](<https://devfeed.tech/tags/load-balancer.md>)

## AI overview

The article argues that CAP theorem is largely irrelevant to engineers building cloud-style distributed systems and cloud applications. It contends that systems can provide both strong consistency and uncompromised availability to clients on the majority side of a partition, while noting that CAP is more applicable to intermittently connected mobile and IoT applications. It also highlights how differing definitions of availability create confusion.

## Source excerpt

Let's Consign CAP to the Cabinet of Curiosities CAP? Again? Still? Brewer's CAP theorem, and Gilbert and Lynch's formalization of it, is the first introduction to hard trade-offs for many distributed systems engineers. Going by the vast amounts of ink and bile spent on the topic, it is not unreasonable for new folks to conclude that it's an important, foundational, idea. The reality is that CAP is nearly irrelevant for almost all engineers building cloud-style distributed systems, and applications on the cloud. It's much closer to relevant for developers of intermittently connected mobile and IoT applications, and space where the trade-off is typically seen as common sense already. We'll start with this excellent diagram from Bernstein and Das's Rethinking Eventual Consistency: CAP interests itself in the first two boxes. If there's no partition (everybody can speak to everybody), we're OK. Where CAP goes off the rails is the second box: if a quorum of replicas is available to the client, they can still get both strong consistency, and uncompromised availability. What do we mean when we say Available? Consider the quorum system below. We have seven clients. Six are on the majority (quorum1) side, and are smiling because they can enjoy both availability and strong consistency (provided the system doesn't allow the seventh client to write). The frowning client is out in the cold. They can get stale reads, but can't write, so they're frowning. The formalized CAP theorem would call this system unavailable, based on their definition of availability: every request received by a non-failing node in the system must result in a response. Most engineers, operators, and six of seven clients, would call this system available. This difference in definitions for a common everyday term causes no end of confusion. Including among those who (incorrectly) claim that this system can't offer consistency and availability to the six happy clients. It can. Can we make the seventh client h