# The unclear CP vs. CA case in CAP

DevFeed: [The unclear CP vs. CA case in CAP](<https://devfeed.tech/articles/the-unclear-cp-vs-ca-case-in-cap-21689.md>)

Original publisher: [Read original article](<http://blog.thislongrun.com/2015/04/the-unclear-cp-vs-ca-case-in-cap.html>)

Author: Nicolas Liochon (noreply@blogger.com)

Published: 2015-04-05T16:53:00Z

Content type: article

Language: en

Sources: [Nicolas Liochon](<https://devfeed.tech/sources/nicolas-liochon.md>)

Topics: [distributed-systems](<https://devfeed.tech/topics/distributed-systems.md>), [Databases](<https://devfeed.tech/topics/databases.md>), [SQL](<https://devfeed.tech/topics/sql.md>), [Protocol (disambiguation)](<https://devfeed.tech/topics/protocol.md>)

Tags: [acid](<https://devfeed.tech/tags/acid.md>), [availability](<https://devfeed.tech/tags/availability.md>), [cap-theorem](<https://devfeed.tech/tags/cap-theorem.md>), [consistency](<https://devfeed.tech/tags/consistency.md>), [database](<https://devfeed.tech/tags/database.md>), [distributed-system](<https://devfeed.tech/tags/distributed-system.md>), [distributed-systems](<https://devfeed.tech/tags/distributed-systems.md>), [durability](<https://devfeed.tech/tags/durability.md>), [latency](<https://devfeed.tech/tags/latency.md>), [network](<https://devfeed.tech/tags/network.md>), [partition](<https://devfeed.tech/tags/partition.md>), [protocol](<https://devfeed.tech/tags/protocol.md>), [sql](<https://devfeed.tech/tags/sql.md>)

## AI overview

This post examines why the CAP theorem's AP, CP, and CA categories can be unclear and may say little about how a distributed system actually behaves. It uses several example architectures, including SQL databases, eventually consistent stores, multiple databases with two-phase commit, and distributed consensus servers, while distinguishing CAP terminology from ACID terminology.

## Source excerpt

This post is part of the CAP theorem series. You may want to start by my post on ACID vs. CAP if you have a database background but have never really been exposed to the CAP theorem. The post discussing some traps in the 'Availability' and 'Consistency' definition of CAP should also be used as an introduction if you know CAP but haven't looked at its formal definition. CAP is a theorem, but it is also widely used to categorize distributed systems and to explain their trade-offs. It looks great: "Hey, it's based on a theorem! This is scientifically proven!" However, the meaning of these categories--AP, CP, CA--is not that clear, leading to an opposite result: the CAP categorization says very little on how the distributed system actually behaves. For example, look at the CA category--Consistent and Available but not Partition-tolerant. A widely accepted opinion is: "Partition cannot be avoided. Your distributed system can just choose to sacrifice either consistency or availability when a partition occurs. So a distributed system cannot be CA, by definition." Indeed, Eric Brewer himself, wrote in 2012 [C3]: "Does choosing consistency and availability (CA) as the '2 of 3' make sense? As some researchers correctly point out, exactly what it means to forfeit P is unclear." Should one use the CA category then? A slide saying that some systems are CA. Does its author really understand CAP? To answer this question, we're going to use CAP to categorize a few different distributed systems: A simple application using a single server with a traditional SQL database. The same application, but with an Eventually Consistent store instead of our traditional SQL one. An application using multiple databases and the two-phase commit protocol. A distributed consensus server, like Apache ZooKeeper or Google Chubby. Also, as we know, using CAP in a database context can be confusing. In this post, I always use CAP terminology and not ACID terminology. When I say "consistent" or "strongly c