Consistency Models

Table of Contents

🔴 P0 — the spectrum from linearisability to eventual consistency

Problem #

When data is replicated, which version does a reader see? The consistency model defines the contract between the system and its users about recency and ordering of data.

The Spectrum #

Model	Guarantee	Cost	Example Use
Linearisability	Reads see the most recent write, globally	Highest (consensus)	Bank account balance
Sequential	All ops appear in some total order consistent with each process	High	Distributed locks
Causal	Causally related ops appear in order; concurrent ops may be reordered	Medium	Social media feeds
Monotonic reads	Once you see a value, you never see an older one	Low	Session-scoped reads
Eventual	All replicas converge eventually; no recency guarantee	Lowest	DNS, CDN, product catalog

Key Insight #

Consistency is not binary. “Strongly consistent” and “eventually consistent” are ends of a spectrum. In practice, you choose different consistency levels for different parts of the same system: linearisable for the payment ledger, eventual for the product catalog.

Instinct #

Name the consistency model explicitly in your design. Don’t say “consistent” — say “linearisable for writes to the balance table, eventually consistent with <5s lag for the activity feed.” This precision is a seniority signal.

References #

Jepsen: Consistency Models — Kyle Kingsbury; interactive map, the definitive visual
Linearizability vs Serializability — Peter Bailis

DDIA 2e Reference #

Chapter 9: Consistency and Consensus — this IS Chapter 9
Chapter 5: Replication and consistency guarantees