It is a set of principles that help architects to make a decision and trade offs within three components of a distributed data store. Cap Theorem states that any distributed data store can provide only two of the following three guarantees:
Consistency
This principle says that all nodes within network should have the same data at the same time. That means, if you change data in one node, the change should be reflected in all of them.
Examples
- Inventory management system, where stock levels needs to be precisely tracked
- Booking systems for limited resources (airline seats, event tickets, hotel rooms) where double booking is a no-no
- Banking systems where the balance of an account must be consistent to prevent fraud
Availability
This principle says that system is always operational and ready to take requests and responses. Availability should be at around 99.99% or 99.999%. Availability may be defined as part of SLA and SLO. This should always be a default unless eventual consistency is unacceptable.
Partition Tolerance
This principle cares about the system ability to operate even when there are network issues.
Most systems will either use CP or AP
- AP - Response returns the most readily available version of the data, which might not be the latest. This is because writes might take some time to propagate when partition is resolved
- CP - Waiting for response from partitioned node might result with an error.
Centralised systems
When building centralised system (RDBM), there’s no network partition, so you get Availability and Consistency
Distributed systems
When building distributed systems, you have network partition (P), so you can only choose one: Availability or Consistency.