Day 228: Consistency Models Spectrum

A consistency model is not a performance tier or a brand label. It is a contract about which histories clients are allowed to observe. The practical question is never "is this database eventually consistent?" but "what surprising stories can my users still see?"

Today's "Aha!" Moment

After CAP, PACELC, and quorums, we have most of the machinery. What remains is to describe what those choices look like from the client's point of view.

That is what consistency models really do.

The aha is:

• consistency models describe the histories your clients are allowed to observe

For example:

• can a read return an older value after the client already saw a newer one?
• can two clients observe writes in different orders?
• can a process read its own write immediately?
• can replicas disagree temporarily about what happened most recently?

Those are not implementation details. They are user-visible semantics.

Once we see that, the "spectrum" becomes much more useful. It is no longer a list to memorize. It is a ladder of increasingly strong promises about what observations are ruled out.

Why This Matters

Imagine a collaborative task app with mobile and web clients.

One user marks a task complete on mobile, immediately opens the web app, and still sees it incomplete. Another teammate sees the update first. A third client briefly sees the task revert and then change again.

Which of those behaviors are bugs?

That depends entirely on the consistency contract.

This is why the topic matters.

Without a precise model, teams say vague things like:

• "it is eventually consistent"
• "reads are mostly fresh"
• "it should converge quickly"

Those phrases are often too weak to guide design.

A stronger conversation is:

• do we require read-your-writes?
• do we require monotonic reads?
• do we require a single global order of writes?
• do we only require eventual convergence?

Those questions connect distributed-systems theory directly to product behavior and debugging expectations.

Learning Objectives

By the end of this session, you will be able to:

1. Explain what a consistency model describes - Frame it as a contract over observable histories, not as a storage-engine implementation detail.
2. Compare common positions on the spectrum - Distinguish eventual, client-centric, causal, sequential, and linearizable-style guarantees at a practical level.
3. Choose a model by client need - Match user experience and correctness expectations to the weakest model that still rules out the wrong surprises.

Core Concepts Explained

Concept 1: Eventual Consistency Is the Weak End of the Contract

Eventual consistency says, roughly:

• if no new writes happen for long enough, replicas will converge to the same value

That is useful, but deliberately weak.

It does not promise:

• that a client will immediately see its own write
• that reads move monotonically forward
• that two clients see writes in the same order right away

So eventual consistency is best understood as a convergence promise, not a session guarantee.

That can be fine for:

• low-stakes replicated caches
• social counters
• feeds where brief staleness is acceptable

But it is often too weak for workflows where a user expects:

• "I just changed it, so I should immediately see the change"

That is why the spectrum does not stop there.

Concept 2: Client-Centric and Causal Models Rule Out Specific Surprises

Between eventual consistency and very strong global models, there is a rich middle ground.

Examples:

• read-your-writes: after I write, I will see my own write
• monotonic reads: once I have seen version X, I will not later see an older version
• causal consistency: if event B depends on event A, no client should observe B without also being able to observe A

These models matter because they map directly to user experience.

For example:

• a user edits a profile and immediately refreshes: read-your-writes matters
• a client paginates through state over time: monotonic reads matter
• a reply should not appear before the original message: causal consistency matters

That is why the middle of the spectrum is often more practical than jumping straight from "eventual" to "linearizable."

ASCII sketch:

weaker ----------------------------------------------> stronger
eventual -> client-centric/session -> causal -> sequential -> linearizable

Each step rules out more strange observable histories, but usually costs more in coordination, metadata, or latency.

Concept 3: Sequential and Linearizable Models Buy Stronger Global Stories

At the strong end, the system starts to look much more like one shared copy.

Two especially important models:

• sequential consistency: operations appear in one global order that respects each client's program order, but not necessarily real-time order
• linearizability: operations appear in one global order that also respects real-time precedence

That real-time part is the big extra cost.

If operation A completed before operation B began, linearizability says every observer must be able to understand the history in that order.

That is why linearizability is such a strong and expensive promise. It rules out many surprising histories, but it often requires:

• stronger coordination
• more waiting
• more sensitivity to slow or partitioned replicas

The useful practical summary is:

Model family          Main thing it rules out
-------------------   ---------------------------------------------
Eventual              Permanent divergence
Client-centric        Session-level surprises for one client
Causal                Seeing effects without their causes
Sequential            Per-client order violations in one global story
Linearizable          Real-time order violations in one global story

That table is more useful than memorizing definitions in isolation.

Troubleshooting

Issue: "Eventually consistent just means a bit stale."

Why it happens / is confusing: Teams simplify the user-visible effect to latency of propagation.

Clarification / Fix: Eventual consistency is weaker than "slightly stale." It allows a broad set of transient anomalies unless stronger session or causal guarantees are added.

Issue: "Sequential and linearizable are basically the same."

Why it happens / is confusing: Both give a single global story.

Clarification / Fix: The difference is real-time order. Linearizability respects it; sequential consistency does not have to.

Issue: "We should always choose the strongest model to be safe."

Why it happens / is confusing: Stronger guarantees sound strictly superior.

Clarification / Fix: Stronger models often cost latency, coordination, and availability under failure. Choose the weakest model that still rules out the wrong user-visible surprises.

Advanced Connections

Connection 1: Consistency Models <-> Quorums

The parallel: Quorum configuration is one of the implementation mechanisms that helps a system move along the spectrum. Stronger observable guarantees usually require stronger or more carefully timed overlap.

Connection 2: Consistency Models <-> Client Experience

The parallel: These are not only storage semantics. They are user-experience contracts. Whether someone sees their own changes, sees causally ordered actions, or sees old state again is directly a product behavior question.

Resources

Optional Deepening Resources

• [PAPER] Linearizability: A Correctness Condition for Concurrent Objects
• [PAPER] Time, Clocks, and the Ordering of Events in a Distributed System
• [BOOK] Designing Data-Intensive Applications

Key Insights

1. Consistency models are contracts over observable histories - They define what clients may and may not see, not just how replicas talk internally.
2. The middle of the spectrum matters a lot - Session and causal guarantees often solve real user problems without paying for the strongest global model.
3. Stronger models rule out more surprising histories, but they cost more - More coordination usually means more latency, more complexity, or both.