Interview Prep Zoneby CuriouserLabs

Question 2 of 5 · staff level

Walk the consistency spectrum — linearizability, sequential, causal, eventual. What does each actually promise?

🎤 Say this first

These are guarantees about what a read is allowed to return, ordered from expensive to cheap. Linearizability: the system behaves as if there were one copy and every operation took effect at a single instant between its call and return — reads see the latest completed write, real time included. Sequential: all nodes see the same total order of operations, but that order need not match wall-clock time (a stale-but-consistent view is legal). Causal: operations related by happens-before are seen in that order by everyone; concurrent operations may be seen in any order — the strongest model that stays available under partition. Eventual: the only promise is that if writes stop, replicas converge — it says nothing about when, or what you read meanwhile. The jump in cost is between causal and linearizable, because only linearizability requires cross-node coordination on the read path.

The full picture

ModelPromiseCostWhere you meet it
Linearizablesingle-copy illusion, real-time orderedquorum/leader round-trip per opetcd, ZK, SELECT … FOR UPDATE, compare-and-swap
Sequentialsame total order everywhere, not real-timeconsensus without read coordinationclassic replicated state machines
Causalhappens-before respected; concurrent = unorderedmetadata (vector clocks), no coordinationCOPS, MongoDB causal sessions, most chat apps
Eventualconvergence if writes stopnone — async replicationDNS, S3 (historically), Cassandra ONE, CDNs
  • The real-time clause is what makes linearizability expensive: if a write completes and then my read starts, I must see it — even from a different client on a different node. That forbids serving reads from a lagging follower without checking, which is why 'read from replicas' is a correctness change, not a performance tweak.
  • Causal consistency is the sweet spot most people want: it kills the anomalies users actually notice — a reply appearing before the message it answers, a delete appearing to un-delete. And crucially it is achievable while remaining available under partition, which linearizability provably is not.
  • Eventual is a floor, not a design: 'eventually consistent' with no bound is untestable. What makes it usable in production is a stated convergence window (replica lag p99 < 200ms), monitoring on it, and a conflict-resolution rule you chose deliberately.
  • Watch the trap of 'strong consistency' — a marketing word, not a model. Ask which one is meant: DynamoDB's 'strongly consistent read' is linearizable per key, not across keys; Cassandra's QUORUM is linearizable only when paired with QUORUM writes and no concurrent conflicts.

🔄 Likely follow-up questions

  • Why can causal consistency survive a partition when linearizability cannot?
  • Is linearizability composable — if two objects are each linearizable, is the pair?
  • How would you actually test a store for linearizability violations?