Logo DWBI.org Login / Sign Up
Sign Up
Have Login?
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
New Account?
Go to Login
By continuing you indicate that you agree to Terms of Service and Privacy Policy of the site.

Understanding CAP theorem

Updated on Sep 29, 2020

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?


Concurrently executing queries see the same valid and consistent data at the same time.


This is a guarantee that every request receives a response about whether it succeeded or failed.


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.