From Ordering Guarantees to Consistency Models

Distributed systems differ not only in what they store but in how they order events. Every read, write, and replica update follows an underlying ordering guarantee, a rule defining how operations appear across replicas.

As these guarantees strengthen, systems exchange availability and latency for stronger forms of consistency. Every distributed system must choose how much order it can really afford.

Let’s climb this ladder of consistency, starting from the weakest.

Eventual Consistency — When Order Doesn’t Matter

Ordering guarantee
No global or causal ordering enforced. Replicas can apply updates in any order and may temporarily diverge.

Consistency model
Given enough time and no new writes, all replicas eventual converge.

How it’s achieved
• Gossip protocols exchange updates between nodes.
• Read repair and anti-entropy sync reconcile differences.
• Conflict resolution via timestamps or CRDTs (conflict-free replicated data types).

Example
Alice writes X=1, then X=2. Charlie might read 2, then later 1, depending on which replica he contacts. Eventually, all replicas agree on X=2.

What you gain: Maximum availability and throughput.
What you lose: Predictability, as reads can return anything until convergence.

Read My Writes — Seeing Your Own Updates

Ordering guarantee
Each client’s own writes are applied in the order they were issued, and that client’s subsequent reads must reflect those writes. Other clients may still see those updates later or in a different order.

Consistency model
A client always sees the effects of its own writes in subsequent reads, even if those writes haven’t yet propagated to other replicas.

How it’s achieved
• Use sticky sessions, routing all of a client’s reads and writes to the same replica.
• Apply write-through policies to ensure local visibility before acknowledging success.

Example
Alice posts “Hello World.” Even if replication lags, she’ll see her post when refreshing her feed.

What you gain: A consistent, predictable view of your own actions. Your updates are always visible to you.
What you lose: No shared global order. Different users may see updates in different sequences.

Monotonic Reads — Never Going Backwards

Ordering guarantee
The system preserves a client’s personal reading order. Values you’ve already seen remain visible or newer, never older.

Consistency model
Monotonic reads ensures your view of the data only moves forward, never backward.

How it’s achieved
• Keep session stickiness or remember the latest version seen.
• Ensure subsequent reads are served from replicas at least that fresh.

Example
Bob checks his account balance and sees £100. A few seconds later, he checks again on another replica, which hasn’t yet applied the £100 update. The system either waits for the lagging replica to catch up or redirect the read to a fresher replica.

What you gain: Predictability in your own reads. The data you see only gets fresher over time.
What you lose: Coordination across clients. Your monotonic view might differ from others’.

Consistent prefix/Causal Consistency — Preserving Cause and Effect

Ordering guarantee
If one operation causally depends on another, everyone must see them in that order. Concurrent operations may appear in different orders.

Consistency model
Replicas preserve cause and effect: you never see an effect without first seeing its cause.

How it’s achieved
• Track dependencies using vector clocks or causal metadata.
• Use causal broadcast protocols that delay delivery until prerequisites are met.

Example
Alice debits £100, then credits £100. Bob can’t see the credit without the debit i.e., cause before effect.

What you gain: Logical correctness of related operations.
What you lose: A single, globally consistent sequence.

Sequential Consistency — Everyone Agrees on an Order

Ordering guarantee
All operations appear in the same total order across replicas, though not necessarily in real-time order.

Consistency model
All clients agree on one global sequence that respects each client’s own order.

How it’s achieved
• Implement Total Order Broadcast (TOB) or a replicated log.
• Every node applies operations in that shared sequence.

Example

Alice writes X=1; Bob’s read may still return 0 if his operation is earlier in the global log i.e., Bob.read(X=0), Alice.write(X=1). This is totally legal because because each client’s operations appear in their own program order. What's guaranteed, however, is that all clients agree on that same sequence once it's established.

What you gain: Cluster-wide agreement on operation order.
What you lose: Real-time alignment. An operation that happens later in wall-clock time might still appear earlier in that global order.

Bounded Staleness — Consistency with a Time Limit

Ordering guarantee
Same total order as sequential consistency, but replicas are allowed to lag within a known bound i.e., either in time or number of versions.

Consistency model
Reads may be out-of-date, but only within a predictable limit.

How it’s achieved
• Replicas follow the same sequence of writes, delayed by at most k versions or t seconds.
• Implemented using version clocks, commit timestamps, or bounded clock skew (as in Google Spanner and Cosmos DB).

Example: Bounded Staleness

Bob’s read at 10:00:09 sees stale data (X=0), but it’s only 9 seconds after the write — within the 10 second bound, so it’s allowed.

Example: Bound violated

At 10:00:15, Replica A is 15 seconds behind, exceeding the configured 10 second staleness window. When Bob reads, the system must delay, retry, or redirect the read to a fresher replica. Returning X=0 here would violate the bounded-staleness contract.

What you gain: Predictable lag and lower latency. A practical compromise between freshness and performance.
What you lose: Strict real-time alignment.

Linearizability — Real-Time Global Truth

Ordering guarantee
Extends total order with real-time awareness. If one operation completes before another begins, every process observes them in that order.

Consistency model
Every read returns the most recent committed value.

How it’s achieved
• Use consensus protocols (Raft, Paxos) to totally order operations.
• Wait for quorum acknowledgements before committing writes.

Example
Alice writes X=1. Bob immediately reads and always sees 1. The system may block his read until all replicas agree on that write.

What you gain: Simplicity and real-time correctness. Reads always reflect the latest state.
What you lose: Latency and availability during network partitions.

The Ladder: From Weak to Strong

Each step up this ladder adds coordination and reduces uncertainty: from gossip to quorum, from local perception to shared truth. As guarantees strengthen, availability drops, latency rises and predictability improves.

Eventual consistency powers high-throughput systems like social feeds and caches while linearizability anchors control planes, configuration stores, and financial systems where correctness is non-negotiable. In the end, every distributed system simply chooses how much order it can afford.

Beyond the Ladder: Stacking Consistency Models by Scope

The ladder of consistency shows how systems strengthen their ordering guarantees i.e., from eventual to linearizable. But real-world systems don’t stop at one rung. They often combine multiple consistency models, each governing a different aspect of behaviour.

Consistency models don’t all compete in the same dimension. Some define how replicas agree, others define what a single client experiences, and yet others constrain how fresh the data must be when served.

When two models operate at different scopes, they don’t contradict one another. They describe orthogonal dimensions of consistency and can safely be stacked together. That’s what stacking by scope means.

A distributed database can layer different scopes of consistency to achieve more practical, user-friendly guarantees:
• At the global scope, it may enforce Causal Consistency so replicas preserve cause-and-effect ordering.
• At the session scope, it can apply Read-My-Writes and Monotonic Reads, ensuring each client’s view of data moves forward without regression.
• At the temporal scope, it might add Bounded Staleness, guaranteeing reads are never older than a defined time or version window.

Together, these layers form a cohesive Session Consistency model, a practical blend of global order, personal continuity, and predictable freshness.

References

1. Replicated Data Consistency Explained Through Baseball, Doug Terry 20140319
2. Replicated Data Consistency Explained Through Baseball - Paper
3. Consistency Guarantees in Distributed Systems Explained Simply
4. Designing Data-Intensive Applications
5. Database Internals