8: Consistency, Availability & Partition Tolerance
Consistency (C):
In a distributed system, consistency refers to the idea that all nodes in the system have the same view of the data at the same time. This implies that any read operation will return the most recent write.
Example: Consider a distributed database where a user writes data to one node. In a consistent system, all subsequent read operations, regardless of the node they are sent to, should return the updated data.
Types of Consistency Models:
Strong Consistency: All nodes in the system have a consistent view of the data. Reads and writes are seen by all nodes in the same order.
Eventual Consistency: Over time, all nodes will converge to a consistent state. It allows temporary inconsistencies immediately after updates but guarantees that, given enough time without new updates, all nodes will have the same data.
Availability (A):
Availability means that every request to a non-failing node in the distributed system receives a response, without guaranteeing that it contains the most recent write. An available system is always responsive, even if it returns stale or outdated data.
Example: In the same distributed database scenario, even if one node fails or is slow to respond, the system remains available as long as other nodes can handle incoming requests.
Types of Availability Models:
Strict Availability: Every request receives a response, even if it means returning an error when nodes are unavailable.
Partial Availability: Some requests may not receive a response when nodes are unavailable, allowing for graceful degradation.
Partition Tolerance (P):
Partition tolerance deals with the system's ability to continue functioning, even when network partitions occur. In a partition-tolerant system, nodes can still communicate despite network failures or splits.
Example: If a network partition occurs, dividing a distributed system into separate components that cannot communicate, a partition-tolerant system will continue to function independently in each partition. This means that even if some nodes are unreachable due to the partition, the system can still respond.
Types of Partition Tolerance Models:
Partition-Intolerant: The system cannot tolerate network partitions and may fail or become inconsistent when partitions occur.
Partition-Tolerant: The system can continue to operate in the presence of network partitions, ensuring that nodes can communicate and provide responses independently.
CAP Theorem
The CAP Theorem, also known as Brewer's Theorem, is a fundamental principle in distributed systems that outlines the trade-offs between three key properties: Consistency (C), Availability (A), and Partition Tolerance (P).
The CAP Theorem states that in a distributed system, it is impossible to simultaneously achieve all three of these properties. A system must prioritize two of the three, making trade-offs based on its specific requirements and use cases.
Examples of Systems with Different CAP Trade-offs:
CA Systems (Consistency and Availability): Traditional relational databases like MySQL or PostgreSQL prioritize Consistency and Availability but may sacrifice Partition Tolerance.
CP Systems (Consistency and Partition Tolerance): Systems like Apache HBase prioritize Consistency and Partition Tolerance but may sacrifice Availability during network partitions.
AP Systems (Availability and Partition Tolerance): Systems like Cassandra or DynamoDB prioritize Availability and Partition Tolerance but may sacrifice strong Consistency guarantees.
In practical scenarios, distributed systems often aim for a balance between these factors based on their specific requirements and use cases. The CAP theorem serves as a guiding principle for architects and developers when designing and selecting distributed systems architecture.
2 / 2
