CAP Theorem
If you are in the mid to senior level of your career as a Software Engineer, you are designing systems as a part of your role and responsibility. There are several questions to ponder and several edge cases to be addressed to build a robust, resilient and secure system.
Introduction
The three most prominent issues that needs to be addressed in all of our system designs Consistency, Availability and Partition Tolerance. There are many resources available on these topics, such as here. A simple one liner on these.
Consistency: Every read receives the most recent write or an error.
Availability: Every request must receive a non-error, non empty response
Get Anuragmishra Dev’s stories in your inbox
Join Medium for free to get updates from this writer.
Partition Tolerance: The system continues to operate despite arbitrary network failures or delays.
The CAP theorem says, in any distributed system setting we can at most achieve 2 out of these three
Note: In distributed systems, network partitions are inevitable. Therefore, Partition Tolerance is a baseline requirement, and the real trade-off is between Consistency and Availability, therefore the two resultant systems available are :
CP Systems: The responses are consistent and partition tolerance is present but availability is not guaranteed. These system would face timed out requests but would guarantee latest and most correct data always.
Google spanner, Apache Zookeeper, etcd and HDFS NameNode are a few such systems
AP System: There would always be responses available to any request that comes, but they can be stale. Consistency is not guaranteed in such systems. Apache Cassandra, Amazon DynamoDB, CouchBase, Riak and DNS are systems that follow this, as high availability is their prime concern.
CA Systems: These systems are theoretically possible but are highly unlikely to be seen in the real world. PostgreSQL or MySQL deployed over a single node are types of this but are highly vulnerable to network partitions and are therefore not used.
A basic thumb rule would be to
This is an interesting concept and a proves to be a very helpful tool in your arsenal when designing a distributed system, when we know what trade off can be beneficial.
Happy designing!
