Consistency Models and Replication Strategies
The spectrum between 'always correct' and 'always fast'. Which guarantee each model gives, how quorums work, and how to resolve conflicts when two writers disagree.
Covers: Linearizability, sequential and causal consistency, eventual consistency, quorums, single- vs multi-leader, conflict resolution, CRDTs
“Eventually consistent” is not one thing, and “strongly consistent” is not the only alternative. There is a well-defined spectrum, and being able to name the exact guarantee your system provides - and the exact guarantee your product needs - is one of the clearest senior signals in a design interview.
30-second answer
Linearizability is strongest: operations appear to occur instantaneously at some point between invocation and response, so the system behaves like a single copy and reads always see the latest completed write. Sequential consistency preserves each client's program order but allows a global order that is not real time. Causal consistency guarantees that causally related operations are seen in order while concurrent ones may differ per observer. Then come the session guarantees - read-your-writes, monotonic reads, consistent prefix - and finally eventual consistency, which promises only that replicas converge if writes stop.
| Model | Guarantee | Cost | Typical use |
|---|---|---|---|
| Linearizable | Single-copy illusion; reads see the latest completed write | Coordination on every operation; cross-zone round trip | Locks, leader election, balances, inventory |
| Sequential | One global order consistent with each client's own order | Cheaper than linearizable; no real-time guarantee | Replicated state machines |
| Causal | Cause precedes effect for every observer | Metadata to track dependencies | Comments, chat threads, collaborative apps |
| Read-your-writes | You always see your own updates | Session routing or a log-position token | Profile edits, settings |
| Monotonic reads | Time never appears to go backwards | Sticky routing per session | Feeds, timelines |
| Eventual | Replicas converge if writes stop | Almost none | Like counts, view counts, DNS, analytics |
Quorums: the arithmetic
With N replicas, W acknowledgements on write and R responses on read, the read and write sets must overlap in at least one replica - which is therefore guaranteed to hold the latest value.
| N | W | R | R+W>N? | Profile |
|---|---|---|---|---|
| 3 | 3 | 1 | Yes | Fast reads, slow writes, no write availability if any replica is down |
| 3 | 1 | 3 | Yes | Fast writes, slow reads, no read availability if any replica is down |
| 3 | 2 | 2 | Yes | Balanced quorum - tolerates one replica failure for both |
| 3 | 1 | 1 | No | Fastest, eventually consistent, stale reads possible |
| 5 | 3 | 3 | Yes | Tolerates two failures; higher latency |
Single-leader, multi-leader, leaderless
| Single-leader | Multi-leader | Leaderless | |
|---|---|---|---|
| Writes go to | One node | Any leader, per region | Any replica (quorum) |
| Conflicts | Impossible | Possible and common | Possible |
| Write availability | Lost during failover | Survives region loss | Survives node loss |
| Complexity | Low | High - conflict resolution required | Medium |
| Examples | Postgres, MySQL, MongoDB | Multi-region Cosmos, CouchDB, offline-first apps | Cassandra, DynamoDB, Riak |
Resolving conflicts when two writers disagree
- Last write wins (LWW) - keep the highest timestamp. Simple, and it silently discards data; clock skew decides your business logic. Acceptable for caches and presence, dangerous for anything a user typed.
- Version vectors - track per-replica counters to distinguish 'newer than' from 'concurrent with'. Detects conflicts precisely, but you still need a policy to resolve them.
- Application-level merge - hand both versions to code that understands the domain. Amazon's classic example: merge two shopping carts by union, so an item is never lost (at the cost of a deleted item occasionally reappearing).
- CRDTs - data types whose merge is commutative, associative and idempotent, so conflicts are mathematically impossible. Counters, sets, and text sequences for collaborative editors. The cost is metadata growth and a restricted set of operations.
Say these points
- Linearizable → sequential → causal → session guarantees → eventual, in decreasing strength and cost.
- Causal consistency prevents the anomalies users actually notice, cheaply.
- R + W > N guarantees overlap, but read repair and anti-entropy are what deliver convergence.
- Multi-leader buys write availability and costs you conflict resolution.
- LWW silently loses data; CRDTs make conflicts impossible by construction.
Avoid these mistakes
- Treating eventual consistency as a single guarantee.
- Assuming quorum reads alone give linearizability.
- Using LWW for user-authored data.
- Choosing multi-leader replication without a conflict-resolution plan.
Expect these follow-ups
- Design conflict resolution for a collaborative to-do list that works offline.
- Why does Spanner need atomic clocks to be linearizable and fast?
- What does read repair do, and when is it not enough?
Showing 1 of 1 questions for consistency-models-and-replication.
Check your understanding
3 questions · no sign-up, nothing stored