Today I Learned

The CAP Theorem is a principle that says a distributed database can only guarantee two of the following three things at the same time:

Consistency (C): Every read gets the most recent write.
Availability (A): Every request gets a response (either success or failure).
Partition Tolerance (P): The system keeps working even if parts of the network fail (e.g., servers can't talk to each other).

Example:

Imagine you have a system with multiple servers that store user data.

Consistency (C): If you update your email address on one server, all other servers will immediately reflect that change.
Availability (A): Even if one server goes down, the system will still respond to your requests.
Partition Tolerance (P): Even if a network issue occurs and some servers can't communicate with others, the system will continue working.

The CAP Theorem says: You can pick two of the three properties (Consistency, Availability, Partition Tolerance), but not all three at once. For example:

CA (Consistency + Availability): If you want consistency and availability, the system might fail when the network partitions.
CP (Consistency + Partition Tolerance): If you want consistency and partition tolerance, the system might not be available (i.e., not respond to requests).
AP (Availability + Partition Tolerance): If you want availability and partition tolerance, the system might serve stale data (not consistent).

Why You Can't Have All Three

1. Consistency and Availability without Partition Tolerance (CA):

Scenario: Imagine a system where you have two servers. You want to guarantee that every request gets a response (Availability) and that all users see the same data (Consistency).
Problem: If a network partition occurs (e.g., one server can't communicate with the other), the system has to choose between responding to requests (Availability) and returning the most recent data (Consistency). It can't do both, because if one server isn't reachable, the system can't guarantee that the data will be the same on all servers.
Conclusion: In the case of network partitions, you must choose Availability over Consistency or Consistency over Availability. Therefore, you can't have both consistency and availability without partition tolerance.

2. Consistency and Partition Tolerance without Availability (CP):

Scenario: Suppose you want to ensure that your system is always consistent (all data is synchronized across servers) and can still function if parts of the network fail (Partition Tolerance).
Problem: In the event of a network partition, some servers might be unreachable, but the system will still ensure that all nodes have consistent data by refusing to answer requests until the partition is resolved. This means Availability is sacrificed — the system might not respond to some requests because it is waiting for the partition to be resolved to keep consistency.
Conclusion: If the system guarantees Consistency and Partition Tolerance, it may not be able to respond to requests during a partition, thus sacrificing Availability.

3. Availability and Partition Tolerance without Consistency (AP):

Scenario: You want your system to respond to every request (availability) and keep working even if some parts of the network fail (partition tolerance).
Problem: If there is a network partition, different parts of the system may start serving different versions of the data because the system will continue to process requests even when some servers can't talk to each other. This can result in inconsistent data between nodes.
Conclusion: In this case, you give up consistency to ensure both Availability and Partition Tolerance.