This is the first of a six part blog post about the CAP Theorem (Brewer’s Conjecture). In this series of posts, we provide a detailed explanation of the CAP Theorem from the perspective of an application developer, and a system architect. It sets forth a framework within which to understand the implications of CAP Theorem, and quantify the implications of various choices on Consistency, Availability and Partition Tolerance.
The first post (this post) provides a brief background, and introduces the CAP Theorem. You can download all six parts in one document here.
Part 1: Background
In having conversations with advisers, investors, prospects and friends about ParElastic and our Elastic Transparent Sharding ArchitectureTM, the conversation very often finds its way to the CAP Theorem.
Some people we speak with are concerned about the future of the relational database itself and cite articles that they have read by well-respected database experts who predict the imminent demise of the relational database. Most database users and ParElastic prospects readily admit their own incredible pain with using databases in the cloud, and some tell us about their nightmares experimenting with NoSQL solutions.
As we often hear about the CAP Theorem, it makes sense to discuss the CAP Theorem in some detail. Ken (who is a founder of ParElastic, and the CEO) and I took some time to dig into the CAP Theorem and we were not too thrilled with what we found. This multi-part blog post is the result of that investigation.
Part 2: An introduction to the CAP Theorem
In his keynote at PODC 2000, Eric Brewer made the case that of the three attributes, Consistency, Availability, and Partition Tolerance, you can have at most two. In particular, I refer in particular to the slide (reproduced below) from his presentation that is available for download at http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf.
This statement leaves wide margin for interpretation (or mis-interpretation).
Nothing in Eric Brewer’s original comments seem to indicate that you have to entirely forsake the unlucky attribute. On the other hand, I believe that the sentiment is that one cannot “guarantee” all three attributes, potentially weakening one of them.
But neither does the CAP Theorem, nor does the original conjecture give one any clear direction on how to quantify the extent of weakening or relaxation on the unlucky attribute! And this has led to a general belief that Consistency, Availability and Partition Tolerance are these binary things that are either there or not there, and that is a great misconception.
Clearing up this misconception is, in a nutshell, the purpose of this multi-part blog post.