CAP theorem simply states that in case of a network failure, when a few of the nodes of the system are down, we have to make a choice between Availability & Consistency. Networks aren’t reliable, so you’ll need to support partition tolerance.
CAP stands for Consistency, Availability, Partition Tolerance.
A read is guaranteed to return the most recent write for a given client.
A non-failing node will return a reasonable response within a reasonable amount of time (no error or timeout).
Partition (Partition Tolerance / Fault Tolerence)
The system will continue to function when network partitions occur. The system is tolerant of failures or partitions.
Why not Partition Tolerance ?
One such fallacy of distributed computing is that networks are reliable. They aren’t. Networks and parts of networks go down frequently and unexpectedly. Network failures happen to your system and you don’t get to choose when they occur.
Given that networks aren’t completely reliable, you must tolerate partitions in a distributed system, period. Fortunately, though, you get to choose what to do when a partition does occur. According to the CAP theorem, this means we are left with two options: Consistency and Availability.
AP – Availability/Partition Tolerance
If we choose Availability over Consistency that means when a few nodes go down, the other nodes are available to the users for making updates. In this situation, the system is inconsistent as the nodes which are down don’t get updated with the new data. At the point in time when they come back online, if a user fetches the data from them, they’ll return the old values they had when they went down.
Choose Availability over Consistency when your business requirements allow for some flexibility around when the data in the system synchronizes. Availability is also a compelling option when the system needs to continue to function in spite of external errors (shopping carts, etc.)
CP – Consistency/Partition Tolerance
Wait for a response from the partitioned node which could result in a timeout error. The system can also choose to return an error, depending on the scenario you desire. Choose Consistency over Availability when your business requirements dictate atomic reads and writes.
If we choose Consistency over Availability, in that scenario, we have to lock down all the nodes for further writes until the nodes which have gone down come back online. This would ensure the Strong consistency of the system as all the nodes will have the same entity values.
The decision between Consistency and Availability is a software trade off. You can choose what to do in the face of a network partition – the control is in your hands. Network outages, both temporary and permanent, are a fact of life and occur whether you want them to or not – this exists outside of your software.