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).
• 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.
• 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.

Takeaways

• Consistency is a spectrum: linearizable → 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.