Consistency models define the guarantees a system provides about the visibility and ordering of operations across replicas in Distributed Systems. They represent the contract between the system and applications about what values reads may return.
The Spectrum
Consistency models form a spectrum from strongest to weakest guarantees:
Strong Consistency (Linearizability)
- Every read returns the most recent write
- Operations appear to execute atomically at a single point in time
- Highest guarantee, highest coordination cost
- Example: Single-leader databases with synchronous replication
Sequential Consistency
- Operations from each process appear in program order
- All processes see the same global order
- Weaker than linearizability (no real-time guarantees)
Causal Consistency
- Causally-related operations maintain order
- Concurrent operations may be seen in different orders
- Tracked using mechanisms like Vector Clocks
- All replicas eventually converge if updates stop
- No ordering guarantees during convergence
- Lowest coordination cost, highest availability
- Example: Dynamo, Cassandra
Trade-offs
The CAP-theorem shows that in Distributed Systems with network partitions, you cannot achieve both strong consistency and availability. Weaker consistency models like eventual consistency sacrifice immediate consistency for availability and performance.
The choice of consistency model fundamentally shapes system behavior:
- Strong: Easier to reason about, but limits availability and scalability
- Weak: Requires application-level Conflict Resolution Strategies, but enables high availability
Systems like Dynamo choose eventual consistency explicitly to ensure “always writeable” behavior, pushing complexity to the application layer through semantic reconciliation.