Consistency Models
Consistency models define the rules for how and when writes become visible to readers in a distributed system.
What are consistency models?
A consistency model is a contract between a distributed system and its clients, defining which reads are guaranteed to reflect which writes. Choosing the wrong model is one of the most common sources of subtle bugs in distributed systems.
The Spectrum of Models
Strong Consistency (Linearisability)
Every operation appears to take effect instantaneously at some point between its start and end. After a write completes, every subsequent read on any node reflects that write.
- Cost: High latency, reduced availability (must coordinate before responding)
- Examples: etcd, Zookeeper, single-node PostgreSQL, Google Spanner
- Use when: financial balances, inventory counts, leader election
Sequential Consistency
All operations appear in some sequential order consistent with each program's order, but not necessarily real-time. All nodes see the same ordering, just not necessarily the globally most-recent ordering.
- Weaker than linearisability - doesn't require real-time ordering
- Used in some CPU memory models
Causal Consistency
Operations that are causally related (A happened before B) are seen in that order by all nodes. Concurrent operations may be seen in different orders.
- Examples: MongoDB with causal sessions, some Cassandra use cases
- Use when: comment threads (a reply must appear after the post it replies to)
Read-Your-Writes Consistency
After a client writes, it is guaranteed to see that write on subsequent reads - even if other clients might still see the old value.
- Common workaround in AP systems: route the same user's reads to the same replica, or read from the primary immediately after writes
- Use when: user profile updates, settings changes
Eventual Consistency
If no new updates are made, all replicas will eventually converge to the same value. No timing guarantee.
- Examples: Cassandra, DynamoDB, DNS, CDN caches
- Use when: social feeds, counters, shopping cart totals where brief staleness is acceptable
Comparing Models
| Model | Latency | Availability | Complexity |
|---|---|---|---|
| Linearisable | High | Lower | High |
| Sequential | Medium | Medium | Medium |
| Causal | Low-Medium | Higher | Medium |
| Read-your-writes | Low | Higher | Low |
| Eventual | Lowest | Highest | Lowest |
Which to Choose When
- Money, inventory, locks -> Linearisable. The cost of a wrong answer is too high.
- User's own data (profile, settings) -> Read-your-writes. They must see their own edits.
- Social content, feeds, counters -> Eventual. Brief inconsistency is invisible to users.
- Collaborative editing, messaging -> Causal. Message ordering must be preserved.
Interview Angle
Be ready to explain eventual consistency and its conflict resolution strategies (last-write-wins, vector clocks, CRDTs). Interviewers often probe: "What happens in your system if two users update the same record simultaneously?" Your answer should map to a specific consistency model and its tradeoffs.