CAP Theorem simplified
If you ever worked with any NoSQL database, you must have heard about CAP theorem. Mr. Brewer spoke about this theorem at Symposium on Principles of Distributed Computing many years way back in 2000.
Similar to Microservices blog, I will go again with the restaurant example. It is most probable that an IT professional driving (well… is there undrive?) in Bangalore traffic, one or the other day will think, let me quit this job and start a restaurant.
Let’s start the story. Srinivas was fed up (it usually happens to 85% of people just after appraisals) with IT job and eventually quit his job to start a restaurant. After careful examination, he started delivery by a phone call. He hired few delivery boys whom he got at very cheaper rates after many food delivery startups vanished in thin air.
Day5: Srinivas chose to operate the call himself while sitting at billing counter. Morning it was lull period. But from 7 pm onwards he started getting many calls. Whatever the order he gets, he writes on a paper, gives it to kitchen and …boom… it is cooked (well, not every time) and delivered to the customer. Around 8:30 pm he saw one customer walking to him. He is gasping for breath and apparently looks angry (maybe hungry inside). “I have been calling for last 30 minutes. Your phone is always engaged. I had to walk for 20 mins to come here to place the order. I am not happy.”
Idea time: Srinivas apparently was not happy and shaken to the core. When he was in IT services field, he was every day told by his bosses that “customer is God and you can’t make God upset”. Being a God fearing person he sacrificed many things in life including going to temple. After some disturbed sleep and thinking time, he got a brilliant idea. “Let me hire one more operator who can take the calls. If one line is engaged, another person will pick up.” It took a week to onboard new person while he dealt with fuming customers for a week. This is improving “Availability”.
Day 15: Now new employee Raj is on-boarded and Srinivas is delighted. Customer’s waiting time in the call drastically reduced. If one line is engaged, calls are automatically transferred to second line. Between Srinivas and Raj things are working well. They were able to take orders and process them.
Day 27: At 8:00 pm Srinivas got a call from a customer. “I placed an order 45 minutes back. What is the status?” Srinivas took his phone number and name and tried looking at his order list. He doesn’t have it. He looked at Raj who is next to him. Raj is busy in taking other orders. He can’t disturb him. Srinivas apologised and asked the customer to wait for 2 mins. Customer is already unhappy and making him wait made him furious. He said “Cancel my order” and disconnected the phone. God fearing Srinivas is again distressed.
Idea time: Srinivas thought bit more about it. He also realized this kind of situation will come to Raj as well. After some thinking time…….Eureka — he found a solution. Next day he agreed with Raj to exchange order details as soon as they take orders. For example order number 223 was taken by Srinivas. He will have the original order and pass the copy of the order details to Raj. Similarly order number 224 was taken by Raj and he will pass the copy to Srinivas. Now they both have all the order details. Later if a customer asks the status, they can answer without keeping the customer in waiting. This is having “Consistency”
Day 283: Everything is going on well so far. The business increased multifold. Now he has 3 people taking orders and he built one more kitchen. Both Srinivas and Raj are not doing this work any more. New team is Suma, Ramesh and Supriya. They are young, vibrant and nonchalant. As per the previous process, each of them updates other two on the orders.
Day 289: All well and good until one fine day. Like in a bollywood movie, Supriya fell in love with Ramesh and Ramesh fell in love with Suma. And things started becoming complicated and Supriya started feeling like a loser. Things became worse with time. Both Ramesh and Suma stopped communicating the order details to Supriya and Supriya also did same. This led to broken communication. Now pretty much things went back to day 1. There is no “Partition tolerance” The only way service can be made available and consistent is by getting rid of either Ramesh and Suma or Supriya or making them work together. Or otherwise you can make system “Available” but with inconsistent data.
Lets come back to reality of our IT world.
CAP stands for Consistency, Availability and Partition Tolerance.
- Consistency (C ): All nodes see the same data at the same time. What you write you is what you get to read.
- Availability (A): A guarantee that every request receives a response about whether it was successful or failed. Whether you want to read or write you will get some response back.
- Partition tolerance (P): The system continues to operate despite arbitrary message loss or failure of part of the system. Irrespective of communication cut down among the nodes, system still works.
Often CAP theorem is misunderstood. It is not any 2 out of 3. Key point here is P is not visible to your customer. It is Technology solution to enable C and A. Customer can only experience C and A.
P is driven by wires, electricity, software and hardware and none of us has any control and often P may not be met. If P is existing, there is no challenge with A and C (except for latency issues). The problem comes when P is not met. Now we have two choices to make.
AP: When there is no partition tolerance, the system is available but with inconsistent data.
CP: When there is no partition tolerance, system is not fully available. But the data is consistent.
It would be a crime if I don’t end the explanation of CAP theorem without the famous CAP triangle and some popular databases.
