Consistency Models in Distributed Systems
AdvancedThe consistency spectrum from linearizability to eventual consistencywhat each model guarantees, which real systems implement each model, and how to design application code for the consistency level your infrastructure provides.
Step 1 of 5
The Consistency Spectrum
Consistency in distributed systems is not binary. There is a spectrum from the strongest (linearizability) to the weakest (eventual consistency), with meaningful models in between. Stronger consistency is safer but has higher latency cost. Weaker consistency is faster but requires application-level handling for anomalies.
Linearizability (strongest): operations appear to execute instantaneously at some point between their invocation and completion, and are globally ordered. Every observer sees the same order. After a write completes, all subsequent reads (from any node) reflect that write.
Sequential consistency: all operations appear to execute in some total order consistent with the program order of each individual process. Unlike linearizability, different observers can see different orders as long as each observer's view is internally consistent.
Causal consistency: operations that are causally related appear in the same order everywhere. Concurrent (causally unrelated) operations may appear in different orders. Captures "happens-before" relationships.
Eventual consistency (weakest): if no new writes occur, all replicas will eventually converge to the same value. No guarantees about when, or about intermediate read values. The default consistency model for most highly available distributed systems.
Consistency spectrum: stronger = safer, slower. Weaker = faster, requires defensive code.
Key Takeaways
- →Consistency is a spectrum: there are meaningful levels between linearizability and eventual consistency
- →Stronger consistency always has higher latency cost: typically one network RTT per level
- →The correct consistency level is the weakest level that still makes your application correct