Consistency models define the guarantees about the order and visibility of operations in distributed systems.
Strong Consistency
Every read sees the latest write. All nodes see the same data at the same time.
Characteristics
- Reads always return the most recent write
- Higher latency due to coordination overhead
- May sacrifice availability during network partitions (CAP Theorem)
Use Cases
- Financial transactions
- Inventory management
- Coordination services (locks, leader election)
Eventual Consistency
Reads may lag behind writes, but all replicas converge to the same state over time.
Characteristics
- Low latency - no coordination required
- High availability
- Temporary inconsistencies are acceptable
Use Cases
- Social media feeds
- DNS
- Shopping cart
- Analytics and metrics
Other Consistency Models
Causal Consistency
- Preserves cause-effect relationships
- If operation A influences B, all nodes see A before B
- Weaker than strong, stronger than eventual
Read-Your-Writes Consistency
- Users see their own writes immediately
- Other users may experience delays
- Common in session-based systems
Monotonic Reads
- Once a user sees a value, they never see an older value
- Prevents “time travel” in distributed systems
Tradeoffs
The choice of consistency model involves tradeoffs:
- Strong consistency: Correctness and simplicity vs. performance and availability
- Eventual consistency: Performance and availability vs. temporary inconsistencies
References
See also: CAP Theorem