[pgaddict]

I think this article from 2012 by Brewer himself is a good read too - a bit shorter and somewhat more comprehensible: http://www.infoq.com/articles/cap-twelve-years-later-how-the...

There's a bunch of other articles listed on the wikipedia CAP page [https://en.wikipedia.org/wiki/CAP_theorem], for example the post by Abadi is worth reading.

The #1 issue is that the "2 out of 3" formulation is utterly misleading, as it sounds as if all the three options are feature of the distributed system. In reality, people don't control "P" - it's a feature of the network. You may be very careful about designing and operating your network, but one day a partition will happen. So "CA" systems are nonsense.

The other problem is that while CAP uses the same basic terms as ACID, the meaning of those terms is entirely different. This makes discussions about the CAP vs. ACID stuff pretty much impossible, because each group thinks Consistency or Availability means the same thing in both worlds. So RDBMS people will shout "We have availability, just like you!" and NoSQL people will shout "We have consistency, just like you!" Madness ...

[lomnakkus]

Re: AVID vs CAP.

You're right about the C(onsistency) bit, but the A in ACID stands for Atomic, not Available.

[pgaddict]

Good point, but I wasn't implying that the "A" in ACID stands for Availability (sorry if that was unclear), but that what people dealing with traditional systems (build on ACID) mean when they speak about "Availability".

For example it may mean a master-slave system with an automatic failover, which is rather different from what Availability means in CAP.

[lomnakkus]

Oh, sorry. The phrasing led me to believe that's what you were saying.

As you were.