Consistency Models: Linearizable Through Monotonic Reads
Definition
A consistency model specifies what ordering and freshness guarantees a client can rely on when reading and writing shared data across replicas or concurrent operations.
- Linearizable — Every operation appears to happen atomically at one instant on a single sequential timeline; real-time ordering is preserved with respect to non-overlapping ops. Strongest single-register intuition for distributed stores.
- Sequential — All operations appear in some global order consistent with each client's program order; weaker than linearizability (may not respect real-time ordering of concurrent ops).
- Causal — If operation B is causally dependent on A (A "happened before" B), all observers see A before B; concurrent ops may be seen in different orders.
- Eventual — If updates stop, replicas eventually converge; no promise on intermediate reads.
- Read-your-writes — A session never reads a value older than what it wrote.
- Monotonic reads — A session never sees older values after having seen newer ones (no time travel backward within a session).
Why it matters in interviews
System design lives or dies on what users observe after a write. Interviewers probe whether you default to "strong consistency everywhere" (usually wrong at scale) or "eventual is fine" (sometimes unsafe for payments or profile updates). Naming read-your-writes and causal boundaries shows seniority.
Tradeoffs
Stronger models (linearizable, sequential) cost latency, availability during faults, and throughput (coordination, fencing, quorums). Weaker models (eventual, monotonic reads) scale better but require explicit handling of duplicates, vector clocks, or session stickiness. Causal sits in a sweet spot for collaborative apps but needs metadata (Lamport/vector clocks or explicit dependency tracking).
Concrete examples
- Bank balance debit/credit — Typically needs strong consistency or serializable isolation on the account—linearizable updates on the balance object, not "eventually consistent" money.
- Social feed ranking — Often eventual for fan-out; read-your-writes for "I posted, then I refresh" via write-through to my timeline or session routing to the primary for a short window.
- Collaborative doc (comments) — Causal matters: replies must appear after parents; total order across strangers may be unnecessary if only causal chains must hold.
How to say it in 30 seconds
"I match the consistency model to the invariant. Financial invariants need strong guarantees; social feeds often use eventual with read-your-writes for the author. I separate replica lag from causal needs—causal needs dependency tracking, not just 'wait a second.'"
Common follow-up questions
- Difference between linearizable and serializable? Linearizable is about single-object real-time order in a distributed setting; serializable is the transaction isolation level across multiple objects (see isolation-levels.md).
- How do you implement read-your-writes? Session affinity to the writer, read from primary after write, version tokens on the client, or bounded staleness checks.
- Is Cassandra eventual only? Tunable per operation with QUORUM, LOCAL_QUORUM, etc.—you choose latency vs staleness.
Cross-links (building blocks)
- Replication, cache invalidation, and CQRS/event sourcing all expose consistency choices—see System design curriculum overview.
See also: System design curriculum overview
Last updated on
Spotted something unclear or wrong on this page?