The CAP theorem states that, in a distributed system, you can only have two out of the three possible guarantees: Consistency (C), Availability (A), and Partition Tolerance (P).
- Consistency → You will get the most recent write content on every read (you can read from any node and get the same data).
- Availability → All reads and writes eventually return a response. No errors or timeouts. (ability to access the cluster even if one of the nodes is down).
- Partition tolerance → System continues working when network partitions happen (both nodes are up, but can’t communicate).
In real life, networks can go down, software needs to be restarted and hardware failures happen. So Partition Tolerance (P) needs to be supported by default. The real tradeoff/choice is then made between consistency and availability.
If the network communication goes down, it means that the updates won’t be synced between multiple nodes. So you have 2 options:
- Consider the system to be down (giving up availability)
- Allow the nodes to get out of sync (giving up consistency)
CONSISTENCY AND PARTITION TOLERANCE (CP)
Reads always retrieve the most recent written content on success. The response can also be a timeout or an error due to the lack of guaranteed availability. Consistency is a good choice when your business require atomic reads and writes.
Use-case example
- Money transactions in banks: We need to guarantee that the balance will always be consistent over time.
AVAILABILITY AND PARTITION TOLERANCE (AP)
Reads will be answered with the available data in the requested node. It has no guarantee that it will be the most up-to-date version of it, since writes take some time to replicate the data. Availability is a good choice for systems that allow flexibility around the data while the system synchronizes.
Use-case example
- Some features in social networks: It is not critical to see the most up-to-date amount of likes in a post, number of followers in a profile or number of comments.
CONSISTENCY PATTERNS
We have some options when it comes to level of consistency required:
- Weak consistency → Reads may or may not see the data that was written
- Use-case example: VoIP/real time systems: If one of the users lose connection, it won’t hear what was said during the offline period
- Eventual consistency → After a write, reads will eventually see the written result. It usually takes few milliseconds for the data to be replicated
- Use-case example: AP (availability + partition tolerance) systems
- Strong consistency → After a write, reads will always see the most up-to-date result
- Use-case example: CP (consistency + partition tolerance) systems
TECHNOLOGY EXAMPLE: MONGODB
By default, MongoDB is strongly consistent: If you do a write and then a read, considering that the write is a success, the read will return the most up-to-date data.
If you enable the feature of reading from secondaries, then MongoDB becomes eventually consistent, which means it is possible to read out-of-date results.