Why can't CP systems also be CAP?

Question

My understanding of the CAP acronym is as follows:

• Consistent: every read gets the most recent write
• Available: every node is available
• Partion Tolerant: the system can continue upholding A and C promises when the network connection between nodes goes down

Assuming my understanding is more or less on track, then something is bother me.

AFAIK, availability is achieved via any of the following techniques:

• Load balancing
• Replication to a disaster recovery system

So if I have a system that I already know is CP, why can't I "make it full CAP" by applying one of these techniques to make it available as well? I'm sure I'm missing something important here, just not sure what.

Answer 1

It's the partition tolerance, that you got wrong.

As long as there isn't any partitioning happening, systems can be consistent and available. There are CA systems which say, we don't care about partitions. You can have them running inside racks with server hardware and make partitioning extremely unlikely. The problem is, what if partitions occur?

The system can either choose to

• continue providing the service, hoping the other server is down rather than providing the same service and serving different data - choosing availability (AP)
• stop providing the service, because it couldn't guarantee consistency anymore, since it doesn't know if the other server is down or in fact up and running and just the communication between these two broke off - choosing consistency (CP)

The idea of the CAP theorem is that you cannot provide both Availability AND Consistency, once partitioning occurs, you can either go for availability and hope for the best, or play it safe and be unavailable, but consistent.

Here are 2 great posts, which should make it clear:

• You Can’t Sacrifice Partition Tolerance shows the idea, that every truly distributed system needs to deal with partitioning now and than and hence CA systems will break instantly at the first occurrence of a partition
• CAP Twelve Years Later: How the "Rules" Have Changed is slightly more up to date and shows the CAP theorem more flexible, where developers can choose how applications behave during partitioning and can sacrifice a bit of consistency to gain some availability, ...

So to finally answer your question, if you take a CP system and replicate it more often, you might either run into overhead of messages sent between the nodes of the system to keep it consistent, or - in case a substantial part of the nodes fails or network partitioning occurs without any part having a clear majority, it won't be able to continue operation as it wouldn't be able to guarantee consistency anymore. But yes, these lines are getting more blurred now and I think the references I've provided will give you a much better understanding.