Discover more from Awesome Software Engineer
The Path to Microservices: CAP Theorem
It has been a long time since the last time we talked about Microservices. Today, I’ll be covering CAP Theorem in a distributed system.
When designing a distributed system, you need to consider consistency, availability, and partition tolerance nature. CAP theorem claims that a system can only deliver 2 out of 3 characteristics which are CP, AP, or CA. You cannot have CAP altogether in a distributed system. However, you cannot deliver CA at the same time since the network is not reliable and you need to consider partition tolerance in a distributed system.
Consistency means every read from the system must be the most recent written. That said, every time you read from any replica, you will get the latest data. The data is consistent across different nodes so the clients can read the same data at the same time.
Availability ensures that the clients can always read and write data to the system but it does not guarantee the data is up-to-date. That means you may have some delay in data propagation.
Partition Tolerance means if a partition error occurs, your system should have the ability to continue or work partially. A partition is a communication break between your application services due to a connection delay or message loss.
A relational database like MySQL or PostgreSQL provides CP to your system because the SQL database offers ACID characteristics to ensure strong consistency. While using NoSQL like MongoDB, offers AP to your system because the NoSQL database is more focused on availability and it is using the BASE model. That said, a NoSQL database is not offering strong consistency but eventual consistency.
Remark: Although most of the NoSQL takes the BASE principle, you can tune the configuration to adjust the consistency level. Here I just want to give you an idea about strong consistency and eventual consistency.
In most of the systems, people tend to have availability more than consistency. I think when talking about CP or AP, it is not strictly saying you don’t have Consistency in the whole system if you want to have more Availability, and vice versa. It is more like how many percent of Consistency or Availability you want in the whole system. If your system is inclined to a higher percentage of Availability, then you will lose Consistency in some services and vice versa.
Thanks for reading Awesome Software Engineer! Subscribe for free to receive new posts and support my work.