I saw a talk Justin Sheehy gave at some point I think last year (or maybe the one before) where he mentioned the CAP theorem, but stressed that it should be thought of not as a dichotomy, but as a continuum. The words he used were “harvest” and “yield” which I believe come from Harvest, Yield, and Scalable Tolerant Systems.
I’m not a big fan of the names “harvest” and “yield” (mostly because they both mean about the same thing to me in terms of farming, so I struggle to remember which is a metaphor for which systems concept), but the important thing is that it’s more of a sliding scale than most people let on when they talk about CAP.
PACELC does a nice job of saying “during a partition, how does the system trade off between availability and consistency”, but I don’t think we need the new acronym. For one thing, it’s longer and less pronounceable.
What we really need to do is talk about how there is a trade-off around how much system wants to communicate globally to handle client requests, and what happens when it can’t. More communication and tight control creates a more CP system that probably has more latency since operations require more network trips. Less communication and looser control creates a more AP system that probably has less latency but allows state on different servers to diverge for a while.
I still will want to call this “CAP” because that’s a nice name.
You’re definitely correct that there’s a continuum. There is a lot of interesting research around the different models that can be offered with different levels of coordination, and how seeing CAP as a dichotomy misses a lot of opportunities to build systems that are practically more useful.
On the other hand, there are some real discontinuities on this spectrum. Various named consistency models (in both the ACID and CAP senses of consistency) have absolute minimum amounts of coordination that are required to achieve them. Linearizability, for example, is a local model which requires strong coordination within the replicas of a single “value”, but no coordination across “values”. Snapshot Isolation, on the other hand, requires less coordination between replicas (but still quite a lot), but significant coordination across “values”.
“The fourth misconception is that eventual consistency is all about CAP, and that everybody would chose strong consistency for every application if it wasn’t for the CAP theorem.”
This is an extremely widespread misconception. CP systems are actually pretty good at availability while not reaching “A” of CAP, since all the clients in the majority partition can make progresses. This is enough HA for most systems. The huge tradeoff in CP systems is performance, that’s why eventual consistency systems are so popular, not because most people need clients able to make progresses in minority partitions (a few use cases definitely require that btw).