CAP Theorem
Fundamental principle in distributed systems.
Tradeoff between desirable properties: Consistency, Availability, Partition Tolerance.
Consistency (C)
Every read receives the most recent write (or an error).
This ensures that all nodes in the system have the same data at any given time.
Availability (A)
Every request (read or write) receives a response, regardless of whether it is successful or not.
The system remains operational even in the presence of some node failures.
Partition Tolerance (P)
The system continues to function even when there is a network partition (a situation where communication between nodes is disrupted).
The Theorem
The CAP theorem states that a distributed system cannot guarantee all three properties simultaneously.
Can only provide at most two out of the three.
Consistency and Availability (CA):
Works well if there are no network partitions.
Examples: Traditional relational databases (if deployed without replication).
Consistency and Partition Tolerance (CP):
Guarantees consistency even during network partitions but may sacrifice availability (e.g., by rejecting requests during a partition).
Examples: Distributed databases like MongoDB (in some configurations).
Availability and Partition Tolerance (AP):
Guarantees availability even during network partitions but may sacrifice consistency (e.g., by allowing nodes to return stale or divergent data).
Examples: Systems like DynamoDB, Cassandra.
Practical Implications
Distributed systems designers must choose which two properties to prioritize based on the application's needs.
Real-world systems often make trade-offs to provide "good enough" versions of all three, but strict guarantees are subject to CAP's limitations.
Example
Consider a banking system:
If consistency is prioritized (e.g., accurate account balances), availability might be sacrificed during network partitions.
If availability is prioritized (e.g., ensuring that ATMs are always operational), consistency might be relaxed during partition events.
Last updated