Understanding CAP theorem
What is the CAP theorem?
CAP is sometimes presented as Consistency, Availability, Partition tolerance pick 2 out of 3.
Unfortunately, putting it this way is misleading because network partitions are a kind of fault, so they aren’t something about which you have a choice: they will happen whether you like it or not.
At times when the network is working correctly, a system can provide both consistency and availability.
When a network fault occurs, you have to choose between either consistency or total availability. Thus, a better way of describing CAP would be either Consistent or Available when Partitioned.
What is the ‘CAP’ in the CAP theorem?
CAP theorem is referred to three characteristics in a distributed system
Consistency
Consistency means that all clients see the same data at the same time, no matter which node they connect to. For this to happen, whenever data is written to one node, it must be instantly forwarded or replicated to all the other nodes in the system before the write is deemed ‘successful.’
Availability
Availability means the probability that a system is operational at a given time. the amount of time a device is actually operating as the percentage of the total time it should be operating. High-availability systems may report availability in terms of minutes or hours of downtime per year. Availability features allow the system to stay operational even when faults do occur.
Partition tolerance
The ability of two nodes of the system (partitions) to proceed in the presence of a temporary communication failure in their network. With more partition tolerance, the database is more available to clients, but the accessible data is less consistent and vice versa
Real-life example to understand CAP theorem
Let us consider a Company that has two stocks and one offer. Company stocks can support
three different operations:
- Place orders
- Check Product total available quantity
Now the employee walks up to a stock. If everything is working, then the system is relatively simple. If the employee sells some products the company needs to update the quantity on the systems and then complete the track. This involves a consistent view of the product quantity as it’s always the same on every stock system. As an employee, he will like to operate the system with whatever operations he wants and also whenever he wants. the stock system needs to be available for him. We will consider the following negative scenario.
Stock with Consistency design
If the stock has chosen a consistent design, then the branch will inform: I can’t accept sell right now because I can’t update the quantity in the other stock. this could be annoying because you will make the customers wait to check if the total quantity enough for their orders
Stock with availability design
In availability design, when you walk up to the Stock and say, I can’t talk to the other stock system. But I will allow you to place the order and will keep track of what happened and then later when the partition heals with the other stock, the account quantity will be updated in another stock. So, with this design, it’s more available, even though stocks are inconsistent in the storage of the product quantities. In a nutshell, this is the cap theorem when you design your system for availability.
Stock with a degree of consistency and availability design
In the real world, we can also consider degrees of consistency and degrees of availability. Also, make trade-offs.
For example, when a partition happens, we can have stocks:
- Accept partial orders
- Not provide total quantity service.
stocks can also provide information about the quantity but only provide tentative quantity information. This means, we are not sure if this is the correct quantity, but it is probably right if you haven’t been running between Stocks.
In short, the stocks decide to make. How much complexity do you want to add to your system, to get higher availability to the employees? Because consistent designs tend to be simpler to build and understand. Complicated availability design can bring conflicts and can become harder or even impossible to resolve.
How does the CAP Theorem affect making database decisions?
Although the CAP Theorem can feel quite abstract, it has practical, real-world consequences. From both a technical and business perspective the trade-offs will lead you to some very important questions. There are no right answers. Ultimately it will be all about the context in which your database is operating, the needs of the business, and the expectations and needs of users.
You will have to consider things like:
- Is it important to avoid throwing up errors in the client?
- Or are we willing to sacrifice the visible user experience to ensure consistency?
- Is consistency an actual important part of the user’s experience
- Or can we actually do what we want with a relational database and avoid the need for partition tolerance altogether?
As you can see, these are ultimately user experience questions. To properly understand those, you need to be sensitive to the overall goals of the project, and, as said above, the context in which your database solution is operating. (Is it powering an internal analytics dashboard? Or is it supporting a widely used external-facing website or application?)
References
Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services
