CAP Theorem explained in 2 Minutes
As the title suggests I will explain CAP Theorem in the same amount of time it takes to listen to a good song.
CAP Theorem in its most basic form is a tradeoff we always will have to make when we get a Network Failure.
We will always have to make a tradeoff it’s an undeniable fact of the universe just like how everyone unanimously agrees that Mondays suck.
You might be thinking however, what is the tradeoff and what on earth does CAP even mean.
Well CAP is an acronym that stands for;
- Consistency
- Availability
- Partition Tolerant
And the theory goes as such…
When making a Distributed System we need to make a tradeoff between Consistency and Availability when we get a ‘Partition’ aka a Network Failure when the two Data Sources are physically partitioned and don't have a connection between them.
We can’t have all three we can only have two.
So do we;
A) Allow Consistency either between Databases or Data Storages / UI by not allowing the user to do certain things until we have a connection with the DB again.
B) Allow for Availability and tradeoff having consistent data across our sources.
You might be asking Kodey, Don’t we always want a highly available system why does it matter.
In Some cases it might actually make more sense to have a Consistency across our data sources for example;
- Booking Seats anywhere so you don’t get overbooked.
- Payment to ensure people can’t pretend to of paid when they haven’t
However in other cases we want to prioritize Availability and tradeoff consistent data across our streams.
For example;
- Editing Notes on your phone
- Playing mobile games offline then syncing after you have a connection
So In summary:
Due to the Universe we can’t have everything we ever wanted to have. And we can only settle on two out of the three. In the case of a network failure we have a choice to make as developers. Do we give the User consistency or availability and that choice will depend on what exactly your priorities are…
