CAP Theorem Explained
CAP theorem applies directly to distributed systems where shared resources communicate over a network to perform database operations. In this article, we'll explain the basics of CAP theorem including how it works and common misconceptions. We'll also look at how the CAP theorem applies to different database implementations used today.
What is CAP theorem?
CAP theorem was developed by computer scientist Eric Brewer. It states that in a distributed data store, it is impossible to provide more than two out of the three following guarantees:
When data is read from the database, it reflects the most recent write. For example, if you query the number of users in a database, it will always reflect the current number of users with 100% accuracy.
Every request receives a non-error response. While the response may not be consistent with the latest DB operation, it is guaranteed to return something relatively accurate.
The distributed system will continue to operate even when network partitions occur. If a node in the system goes down, things will keep working as expected (also known as fault-tolerance).
The CAP theorem is largely based on the assumption that network failures are inevitable and will always occur. When such partitions occur, you must choose between either consistency or availability. When you choose consistency, error messages will result if database requests fail. When you choose availability, data will still be returned but may lack accuracy due to network failures.
CAP Theorem Misconceptions
A common misconception with CAP theorem is that you must choose two out of three. The reality is that you can have all three (consistency, availability, partition tolerance) providing there are no network failures. In other words, it's only really C and A that you must prioritize when network partitions occur.
Additionally, it's not all or nothing when choosing between A or C. Network failures can be handled on a more granular basis to emphasize either C or A on a case by case basis. In other words, you don't have to fully commit to either C or A. You can mix and match based on the needs of your system.
CAP Theorem Applied
Database systems that follow ACID (most traditional RDBMS) typically emphasize consistency over availability. This differs from BASE (NoSQL) implementations which choose high availability over consistency.
The decision on what to emphasize within your distributed system is largely specific to your system's needs. If the business case requires atomic reads and writes, then you would prioritize consistency over availability. If high availability is a must, then obviously A should be emphasized over C.
It's important to remember that CAP theorem does not mean a hard choice between consistency, availability, and fault-tolerance. You really must only prioritize either C or A based on a network failure event. Furthermore, how you handle network failures can differ based on specific functionality within your cluster.>