From Linearizability to Eventual Consistency

Why definitions matter

"Strong consistency" is ambiguous until you specify what clients can observe. Interviewers want precise terms and trade-offs, not buzzwords.

The spectrum (strongest → weakest)

Linearizability

Every operation appears to take effect atomically at some point between its start and end. Strongest single-object guarantee; expensive (often needs consensus or single leader).

Interview example: After write(x=1) completes, every subsequent read(x) returns 1.

Sequential consistency

All operations appear in some total order consistent with each client's program order, but that order need not respect real-time (no simultaneous wall-clock constraint).

Causal consistency

If operation A causally affects B (same session, or read-your-write chain), everyone sees A before B. Concurrent writes may be seen in different orders.

Vector clocks detect causality (Topic 5).

Eventual consistency

If writes stop, all replicas converge to the same value. No bound on how stale a read may be during churn.

Dynamo, Cassandra, and many caches operate here by default for some paths.

Comparison table (memorize)

Model	Stale reads?	Ordering across clients?	Typical cost
Linearizable	No	Total order	High (coordination)
Sequential	Maybe vs real-time	Total order	High
Causal	Bounded by causality	Per-causal-chain	Medium
Eventual	Yes	None guaranteed	Low

What databases actually provide

• etcd / ZooKeeper / Consul — linearizable reads/writes on the coordination path
• PostgreSQL primary — linearizable on the leader (single writer)
• Cassandra — tunable per query (ONE vs QUORUM vs ALL)
• S3 — read-after-write consistency for new objects (evolved over time); list operations historically eventual

Name the operation, not just the product.

Jepsen awareness

Kyle Kingsbury's Jepsen tests real databases under partition and proves which claims hold. You don't need to memorize every test — know that claimed consistency ≠ observed consistency without verification.