Deconstructing CAP Theorem

After reading a blog post entitled “Xeround and the CAP Theorem”, John Hugg made an interesting comment.

…in the face of a network event, the system [Xeround] becomes unavailable, but remains consistent. I think you have partition tolerance, but with reduced availability. I’m not criticizing this approach, as it’s similar to what we do at VoltDB.

You might want to check out some of Dan Abadi’s posts on CAP, like:

He goes into more detail than me as to why it’s really only a choice between CA and AP.

There you have it.

Daniel Abadi of the abovementioned url said it best:

…as far as I can tell, there is no practical difference between CA systems and CP systems. As noted above, CP systems give up availability only when there is a network partition. CA systems are “not tolerant of network partitions”. But what if there is a network partition? What does “not tolerant” mean? In practice, it means that they lose availability if there is a partition. Hence CP and CA are essentially identical. So in reality, there are only two types of systems: CP/CA and AP. i.e., if there is a partition, does the system give up availability or consistency? Having three letters in CAP and saying you can pick any two does nothing but confuse this point.

But my main problem with CAP is that it focuses everyone on a consistency/availability tradeoff, resulting in a perception that the reason why NoSQL systems give up consistency is to get availability.

It resonates exactly with my viewpoint at IT Primer:

My interpretation of CAP Theorem from a system point of view is that, partition tolerance and availability are just two sides of the same coin.

Availability is a subjective term. It depends on the skillset of the operations team, the state of the system itself and anything else in between.

So here is my argument: Just drop A in CAP Theorem. It’s either C or P.

Your system is either ACID Consistent or P (partitions data).

NoSQL relaxes consistency for partition tolerance for scalability, availability or durability reasons. Consistency in this context is strong consistency defined in terms of ACID (all-or-nothing) in contrast with NoSQL and its weak consistency features (eventual consistency, single-data-item transactions and ACID-enabled middleware).

It’s not about ACID systems can’t scale or NoSQL are not consistent. It’s all about whether systems are ACID-consistent or not. It’s just that simple.

Or maybe not. Xeround is ACID-consistent in the front-end but NoSQL in the back-end. Interesting, huh?