Unfortunately, this guy doesn't understand the CAP theorem at all.<p>Once you are distributed, P is not an optional. Rather, in the case of network failure, consistency or availability is what suffers. A system cannot be both CA and distributed.<p>So, for example, Elasticsearch is not a 'CA' solution despite the diagram in the article, but is actually closer to PC (although, in practice it is far more subtle than even that as it is not perfectly consistent, and configuration options allow for some trade-offs between availability and consistency in the case of communication errors.
As others have said, that article is very misleading. Some better ones:<p>* <a href="http://research.microsoft.com/apps/pubs/default.aspx?id=192621" rel="nofollow">http://research.microsoft.com/apps/pubs/default.aspx?id=1926...</a> - including a very nice way of thinking about CAP and tradeoffs)<p>* <a href="http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed" rel="nofollow">http://www.infoq.com/articles/cap-twelve-years-later-how-the...</a> - a good perspective on CAP, and why many people still don't understand it clearly.<p>* <a href="http://lpd.epfl.ch/sgilbert/pubs/BrewersConjecture-SigAct.pdf" rel="nofollow">http://lpd.epfl.ch/sgilbert/pubs/BrewersConjecture-SigAct.pd...</a> - don't get put off by the formal language. Gilbert and Lynch is still (IMO) the best explanation of what CAP means, and what it implies.<p>* <a href="http://blog.cloudera.com/blog/2010/04/cap-confusion-problems-with-partition-tolerance/" rel="nofollow">http://blog.cloudera.com/blog/2010/04/cap-confusion-problems...</a> - Some good criticism of the way CAP is frequently explained.<p>* <a href="http://codahale.com/you-cant-sacrifice-partition-tolerance/" rel="nofollow">http://codahale.com/you-cant-sacrifice-partition-tolerance/</a> - Why CA systems don't actually exist.<p>* <a href="http://cs-www.cs.yale.edu/homes/dna/papers/abadi-pacelc.pdf" rel="nofollow">http://cs-www.cs.yale.edu/homes/dna/papers/abadi-pacelc.pdf</a> - PACELC, maybe a better model.<p>* <a href="http://dbmsmusings.blogspot.com/2010/04/problems-with-cap-and-yahoos-little.html" rel="nofollow">http://dbmsmusings.blogspot.com/2010/04/problems-with-cap-an...</a> - Another look at PACELC, with some examples.
For those who want to read about real tests of how various common software fares under network partitions, here is some amazing work done by aphyr and his infamous Jepesen tests:<p><a href="http://aphyr.com/tags/jepsen" rel="nofollow">http://aphyr.com/tags/jepsen</a><p>This post has some info on elastic, but nothing in excruciating detail:
<a href="http://aphyr.com/posts/288-the-network-is-reliable" rel="nofollow">http://aphyr.com/posts/288-the-network-is-reliable</a>
In many talks and presentations, I have heard that only eventual consistency was possible in a distributed system. since, A and P are already needed, you can only compromise on C.<p>Therefore, I am curious in knowing. Here's my question: how do they configure production systems in order to get reasonable or 100% maybe consistency? In other words, the reads must factor latest write into account. No, stale reads.
"Consistency around CAP is similar to what you find in a typical ACID model - except that, now, we're in a distributed model."<p>I thought that consistency in ACID meant that data was always consistent with the rules of the database, whereas in CAP it means that the same data held in different locations is the same? Is that not right?