Consistency Models
Consistency models in distributed systems describe what reads and writes see across replicas and nodes. Strong consistency (e.g. linearizability) guarantees that any read sees the latest write; eventual consistency guarantees that, with no new writes, all replicas converge after some time. This article explains common models and when to use them with a comparison table.
Overview
- Strong / Linearizability: Every read sees the result of the "most recent write"; all operations can be ordered in a global sequence consistent with real-time order. Expensive to implement; usually via consensus (Paxos/Raft) or single-leader.
- Sequential consistency: Operations can be ordered globally but need not match real-time; each process’s local order is preserved. Weaker than linearizability.
- Causal consistency: Causally related operations have the same order on all nodes; unrelated operations may be reordered. Stronger than eventual.
- Eventual consistency: No guarantee at any instant; guarantees convergence when writes stop. Common in AP systems (Cassandra, Dynamo-style).
Example
Example 1: Strong vs eventual
- Strong: A writes x=1; B immediately reads x and gets 1 (or a later write). Use for balance, inventory, etc.
- Eventual: A writes x=1; B may read 0 briefly; after some time, replicas sync and B reads 1. Use for likes, view counts, and other metrics that tolerate brief inconsistency.
Example 2: Model comparison
| Model | Does read always see latest write? | Typical implementation |
|---|---|---|
| Linearizability | Yes | Single-leader + synchronous replication, consensus |
| Sequential | Globally ordered, not necessarily real-time | Some distributed stores |
| Causal | Causally related operations ordered | Version vectors / vector clocks |
| Eventual | No; converges after some time | Async replication, CRDT, conflict resolution |
Example 3: Choosing a model
- Finance, inventory, permissions → strong consistency or transactions.
- Social counts, recommendations, logs → eventual consistency often acceptable.
- Balance consistency, availability, and latency (CAP).
Core Mechanism / Behavior
- Linearizability: Requires coordination (e.g. consensus, single-leader). Every read reflects a globally ordered write.
- Eventual: Replicas propagate writes asynchronously; conflict resolution (LWW, CRDT, merge) when they diverge.
- Causal: Version vectors or vector clocks track causal dependencies; enforce order only for causally related operations.
Key Rules
- Pick a model by business needs; use eventual consistency when strong is unnecessary to reduce cost and improve availability.
- Eventual systems need conflict resolution (LWW, CRDT, business merge) and versioning/timestamps to avoid lost writes or wrong order.
- Strong consistency usually relies on single-leader or consensus; has latency and availability cost; multi-site and cross-region need extra design.
What's Next
See CAP Theorem and Distributed Transactions. See MVCC and Redis for single-node and distributed read/write consistency.