Understanding CAP theorem
Despite the high demand in recent years for massively distributed databases with high partition fault-tolerance, the CAP theorem stipulates that it is actually impossible for a distributed system to provide consistency, availability and partition fault-tolerance guarantees simultaneously; a distributed system can satisfy at most any two of these guarantees at the same time, but not all three. Let's understand this in detail.
Understanding the CAP
So what does the 3 letters of CAP actually mean?
Consistency
Concurrently executing queries see the same valid and consistent data at the same time.
Availability
This is a guarantee that every request receives a response about whether it succeeded or failed.
Partition-tolerance
Also known as fault-tolerance, this is a guarantee that the system continues to operate despite arbitrary message loss.
Because no distributed system is capable of satisfying all three guarantees at the same time, a tradeoff must be made. While traditional databases make that decision for us, NoSQL databases provide these guarantees as tuning options. Database vendors must always decide which two to prioritize. The options are as follows:
- Availability is compromised in favour of consistency and partition-tolerance.
- Partition-tolerance is forfeited in favour of consistency and availability.
- Consistency is compromised but systems are always available and can work when parts are partitioned.
Traditional SQL databases place a high priority on consistency and fault-tolerance and have generally as a result chosen to go with the first option above and forfeit high availability. NoSQL databases frequently leave that decision to the application operations team and provide configuration options so that the preferred options can be chosen based on the application use case.