Consistency Models

In one line

Consistency models define which values a read may return. Linearizability (strong consistency) makes the system behave like a single copy in real time; sequential and causal consistency relax real-time ordering; session guarantees (read-your-writes, monotonic reads) fix the most visible anomalies for a single user; eventual consistency only promises convergence. Conflict resolution decides what happens when replicas accept concurrent writes.

0/5 · 0%

Think of it like this

News spreading through a town. Linearizable is a single noticeboard everyone reads. Causal is gossip that never tells you a reply before the question. Eventual is gossip that reaches everyone sooner or later, in any order.

Key ideas

01
Linearizability: once a write completes, every later read (by anyone) sees it or something newer. Needed for locks, leader election, uniqueness and balances. It costs coordination (consensus or a single leader) and cross-region latency.
02
Sequential consistency: all clients see operations in the same order, consistent with each client's program order, but not necessarily real time. Causal consistency: causally related operations (a reply after a post) are seen in order by everyone; concurrent ones may differ.
03
Session guarantees: read-your-writes (you see your own updates), monotonic reads (you never see time go backwards across reads), monotonic writes, writes-follow-reads. Implemented with sticky routing, version tokens, or LSN-aware replica reads.
04
Eventual consistency: if writes stop, replicas converge. The questions are how stale reads can be (bounded staleness) and how conflicts are resolved.
05
Conflict resolution for multi-writer systems: last-write-wins by timestamp (simple, silently loses data, and clocks skew), version vectors to detect concurrency and keep siblings for the application to merge (Riak, Dynamo-style), CRDTs (counters, sets, text) that merge automatically, or application rules (a cart merges items; a booking rejects the later one).

Code & diagrams

consistency-ladder.txttext

Strongest
  Linearizable        single-copy behaviour in real time      (etcd, Spanner, single PG primary)
  Sequential          one global order, not real time
  Causal              cause before effect for everyone        (MongoDB causal sessions)
  Session guarantees  read-your-writes, monotonic reads        (sticky routing, LSN tokens)
  Eventual            converges when writes stop               (DNS, async replicas, Cassandra ONE)
Weakest

Interview problem

The problem

Pick consistency per feature of a social app

For a social app, choose a consistency level for: (a) username uniqueness, (b) a user's own profile edits, (c) the like count on a post, (d) comments on a thread, (e) account balance for in-app purchases.

When it breaks

Last-write-wins with skewed clocks

What you see

A node whose clock is 3 s ahead wins every conflict; an older update overwrites a newer one and the loss is silent.

Fix & prevent

Use version vectors or a single writer per key; if LWW is acceptable, use hybrid logical clocks and bound clock skew.

Explain it without notes

What's the difference between linearizability and serializability?

Practice

Explain monotonic reads with an example of it being violated.

Trade-offs

↔
Stronger models simplify reasoning and cost latency and availability; weaker ones scale and survive partitions but push complexity into the application.

Done when you can

I can name consistency models and choose one per feature with a justification.

Command Palette