The Consistency Spectrum — Linearizable to Eventual (CAP/PACELC lens)

Consistency isn't yes/no — it's a dial

People say a system is "consistent" or "not," but consistency is a spectrum of guarantees, each trading correctness for coordination cost, latency, and availability. Knowing where on the dial your data needs to sit — per use case, not per system — is a core systems-design judgment.

The levels, strongest to weakest

• Linearizable (strong): every read sees the most recent write — the system behaves like a single copy. Needed for balances, locks, leader election, "is this username taken?". Costs cross-node coordination → higher latency, and under a partition you must drop availability (CAP: CP).
• Sequential: every process sees all operations in the same single order, and each process's own ops appear in program order — but that shared order need not match real time. The canonical picture: serve every read from one asynchronously-updated follower — everyone sees the same (stale) history, so it is sequential, but a read can miss a write that already committed, so it is not linearizable. The difference is exactly the real-time recency guarantee — which is what linearizability charges the coordination latency for.
• Causal: operations that are causally related are seen in order by everyone (you never see a reply before its message); concurrent ops may differ. The pragmatic sweet spot for chat, comments, collaborative apps — strong enough to feel right, cheap enough to stay available. In fact causal is provably the strongest consistency you can keep while remaining available under partition (Mahajan, Alvisi & Dahlin's real-time-causal result) — anything stronger (sequential, linearizable) forces coordination that a partition can block. That is why it is the ceiling for partition-tolerant collaborative apps: you never see a reply before its message, yet no write ever waits on a remote quorum. Mechanism: each write ships with its causal dependencies (version-vector metadata), and a replica delays applying it until those dependencies have arrived.
• Eventual: replicas converge eventually; a read may be stale. Cheapest, most available — right for likes, view counts, feeds, DNS. Pair with conflict resolution (LWW, or CRDTs for merge-without-loss).

CAP / PACELC as the lens

CAP: during a network partition, you must choose Consistency or Availability — not both. PACELC adds the everyday case: else (no partition), you still trade Latency vs Consistency.

So the design question is: "for this data, what's the cost of a stale or out-of-order read?" A wrong bank balance is unacceptable (linearizable); a like count off by 3 for a second is fine (eventual). The replication-lag anomalies (read-your-writes, monotonic reads) are exactly what weak consistency feels like — and the fixes (session pinning) are how you buy back just enough.

Concrete timeline: a stale read and how session guarantees repair it

Imagine a Twitter-like service with a leader in region A and a follower in region B. Replication lag is 200 ms.

Time	User action	What the system does	What the user sees
t=0	Alice posts "hello" from region A	Write goes to the leader in A	—
t=50 ms	Alice switches to region B and refreshes her feed	Read is served by the follower in B, which has not yet received the post	Alice's own post is missing
t=200 ms	Alice refreshes again	Follower has now caught up	Post appears

This is a read-your-writes anomaly under eventual consistency. Alice wrote the post; one refresh later she cannot see it. The fix is a session guarantee: for a short window after Alice's write, route her own reads to the leader (or to a follower that has already applied her write). The cost is slightly higher read latency for Alice's own requests and a tighter coupling between the write path and the read path; the win is that everyone else's reads can still be served from the cheap follower (DDIA ch. 9).

Buy back just enough consistency — per key, not per system

You rarely need one consistency level for a whole system. Real stores let you dial it per request or per key: DynamoDB defaults to eventually-consistent reads but exposes a ConsistentRead flag to force a strong read on the few paths that need it; Spanner offers bounded-staleness reads ("no older than 10 s") that serve from a nearby replica while capping how stale the answer can be. Reach for these before making every read linearizable.

One distinction to state explicitly under a hostile panel: ACID on a primary is not the same as CAP's "C" across replicas. A single node can be perfectly ACID and still serve non-linearizable reads from its async followers — CAP consistency is linearizability of the distributed object, not the local transaction's isolation level.

Takeaways

• Consistency is a spectrum: linearizable → sequential → causal → eventual, trading correctness for latency/availability.
• Choose per use case: balances/locks → strong; chat → causal; likes/feeds → eventual.
• CAP (partition: C or A) and PACELC (else: latency or C) are the lens for the trade.

---

Re-authored for this guide; spectrum diagram hand-authored as SVG. Follows DDIA ch. 9, Abadi's PACELC, and Jepsen's consistency hierarchy. See also: CAP Theorem, PACELC, Replication Lag & Failover, Quorum.

I just read a lesson on **The Consistency Spectrum — Linearizable to Eventual (CAP/PACELC lens)** (System Design) and want to truly understand it. Explain The Consistency Spectrum — Linearizable to Eventual (CAP/PACELC lens) from first principles using ONE vivid real-world analogy and a visual mental model — draw it as ASCII art or a clear step-by-step diagram — with a concrete example using real numbers. Then ask me one question to check I got the mental picture, and wait for my reply. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Teach me **The Consistency Spectrum — Linearizable to Eventual (CAP/PACELC lens)** interactively. Ask me ONE guiding question at a time, wait for my answer, and adapt to my confusion — build the idea with me step by step instead of explaining it all at once. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Quiz me on **The Consistency Spectrum — Linearizable to Eventual (CAP/PACELC lens)** with 5 questions, easy to tricky, ONE at a time. Tell me if each answer is right; at the end, explain clearly what I got wrong and why. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Help me remember **The Consistency Spectrum — Linearizable to Eventual (CAP/PACELC lens)** for the long term: give the one-sentence intuition, a memorable hook/mnemonic, a tiny worked example, and 3 active-recall flashcards (Q -> A). If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.