· Sergiy Oliynyk · Software Architecture · 2 min read
CAP Theorem
Implications of the CAP theorem.
You have probably heard of the CAP theorem, which describes trade-offs in distributed systems: consistency (C), availability (A), and partition tolerance (P) — you can guarantee only two of these three.
But what does it mean? Let’s dive in!
A distributed system consists of two or more nodes connected to each other via a network.
Consistency
Every read receives the most recent write or an error. In other words, all nodes in the system have the same data.
Availability
Every request (read or write) receives a response, even if some nodes in the system are down. However, the data might not always be up to date.
Partition Tolerance
The system continues to operate even if network failures split the network into partitions.
In distributed systems, partitions are almost inevitable. Because of that, we usually want to guarantee Partition Tolerance and, in practice, must choose between Consistency and Availability.
CA (Consistency + Availability)
This scenario makes sense only if partitioning is very unlikely (for example, if all nodes are located in the same data center). By sacrificing Partition Tolerance, we can guarantee both consistency and availability, but in the event of a partition, the system can become completely unavailable.
CP (Consistency + Partition Tolerance)
Data remains consistent during network partitions, but some parts or functions of the system can be unavailable. Sacrificing availability doesn’t mean that all the system’s functions become unavailable. The main node can continue working as usual, and some other nodes can still provide limited functionality. This scenario is preferable for banking systems.
AP (Availability + Partition Tolerance)
Prioritizes availability over consistency: during network partitions, the system continues providing all functionality to users, but some data can be inconsistent between nodes. This scenario is usually used in e-commerce systems.
Conclusion
So, in other words, we could say that a distributed system will probably be partitioned at some point, and we should develop our architecture to maintain either availability or consistency, depending on our priorities.
