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 reads (default), ZooKeeper writes, DynamoDB consistent reads, compare-and-swap
Sequentialsame total order everywhere, not real-timeconsensus for writes, no read coordinationZooKeeper reads (stale until you call sync), classic 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 read+write gives you quorum overlap, not linearizability (a partially applied write can be seen by one read and not the next — only LWT/Paxos is linearizable there).
  • Even the coordination services differ, and it's a favourite probe: etcd serves linearizable reads by default (it pays a ReadIndex round-trip; WithSerializable opts out). ZooKeeper does not — its writes are linearizable but reads are served locally by any server and may be stale, so ZooKeeper is sequentially consistent unless you issue sync before the read. 'Which of your reads are linearizable?' is a sharper question than 'is this database strongly consistent?'.

🔄 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?