The Consistency Spectrum

Consistency models live on a spectrum. The strong end gives the application a single, coherent view of the world; the weak end gives it the messy reality of replication lag and concurrent writes, in exchange for lower latency and higher availability.

---------- The consistency spectrum ----------
  STRONGER (slower, less available)
  |
  | Strict serializability
  | Linearizability
  | Sequential consistency
  | Causal consistency
  | Read-your-writes / Monotonic reads / Monotonic writes (session guarantees)
  | Eventual consistency
  |
  WEAKER (faster, more available)

The further down you go, the cheaper it is to provide and the more anomalies the application has to deal with. The right model is the weakest one that the user can tolerate.

Strong Consistency: Linearizability

Linearizability (also called atomic consistency) is the gold standard. Every operation appears to take effect at a single instant, instantaneously visible to all clients, in the order they actually happened in real time.

If client A writes x = 1 at 10:00:00.000 and client B reads x at 10:00:00.001, B sees 1. There is no way to observe a state that was not the most recent committed state.

Implementation cost: requires synchronous coordination on every write. Every write must be acknowledged by enough replicas to guarantee that any subsequent read sees it. This typically means a consensus round trip (Raft, Paxos, or 2PC) on every write.

Latency cost: 10 ms within a region, 100 ms across regions. Spanner notably uses TrueTime to bound clock uncertainty and add a 'commit wait' to give global linearizability.

Availability cost: a partition that prevents quorum stops writes entirely.

Examples: Google Spanner, etcd, ZooKeeper, single-instance PostgreSQL, MongoDB with w: majority and readConcern: linearizable, FoundationDB.

Strict Serializability

Linearizability for single-key operations + serializability for multi-key transactions. A transaction's effects appear to take place atomically and in real-time order. This is what most people actually want when they say 'strong consistency'.

Spanner provides strict serializability. Most other 'strongly consistent' systems provide one or the other: linearizability per-key (etcd, Cassandra QUORUM) or serializable transactions on a single shard (PostgreSQL).

Sequential Consistency

Slightly weaker than linearizability. All clients agree on the order of operations, but that order does not have to match real time. If A writes at 10:00:00 and B reads at 10:00:01, B might see the old value - as long as everyone agrees on the same global ordering.

Sequential consistency is rarely a deliberate choice in modern systems; it shows up implicitly in some replicated state machines. Useful to know it exists so you can recognize it in academic papers.

Causal Consistency

A pragmatic middle ground. The system guarantees that operations causally related to each other are observed in the right order, while operations with no causal relationship can be observed in any order.

Causal relationships:

• A reply must be observed after the message it replies to.
• A photo upload must be observed before the like that references it.
• An update to an account balance must be observed before the email that confirms the new balance.

---------- Causal consistency in a chat ----------
  user A: 'I'm at the cafe'        (write 1)
  user B: 'On my way!'             (write 2, depends on read of write 1)

  Required: every observer sees write 1 BEFORE write 2.
  Allowed: an unrelated write 3 ('weather: sunny') can appear in any order.

Implementation: clients track a vector of seen writes; the server only serves a read that includes all causally-prior writes the client has seen. Often implemented with vector clocks or Lamport timestamps.

Examples: COPS, Bayou, MongoDB with causal consistency sessions, Riak with causal context, AntidoteDB.

When to use: chat systems, social networks, collaborative editors, anywhere a user could observe an effect before its cause.

Eventual Consistency

The weakest model in common use. The only guarantee: in the absence of new writes, all replicas eventually converge to the same value. 'Eventually' is unbounded by definition; in practice it is milliseconds to seconds.

Eventual consistency does not promise:

• That you can read what you just wrote.
• That successive reads return values in any sensible order.
• That related writes are observed together.

---------- Eventual consistency in action ----------
  T0  client writes 'name=Bob' to replica A
  T0  replica B still has 'name=Alice'
  T1  client reads from B -> 'Alice' (stale)
  T2  replica B receives the write
  T3  client reads from B -> 'Bob' (now consistent)

This is the default in DynamoDB, Cassandra (with low consistency levels), Riak, S3 (until 2020 it was eventually consistent for overwrites).

When to use: anywhere the cost of an extra second of staleness is lower than the cost of a slower system. Like counts, view counts, recommendation feeds, IoT telemetry, click-stream ingestion, leaderboard updates.

Session Guarantees: The Useful Middle

For most user-facing applications, you do not actually need linearizability across all clients - you need each client's own session to behave sanely. The four session guarantees cover the most common needs.

Read-Your-Writes

Guarantee: after a client writes, that same client always reads its own write back.

Why you need it: a user updates their profile, refreshes the page, and expects to see the change. Without this guarantee, the refresh might hit a stale follower.

Implementation:

• Route reads of a session's own data to the leader for a short window after a write.
• Track the latest write timestamp per session and only read from a follower that has caught up.
• Keep a write-through cache that makes the new value visible immediately.

Monotonic Reads

Guarantee: if a client reads value v at time T, it never reads an older value at time T + 1. Reads only ever move forward in time.

Why you need it: a user keeps refreshing a stock price; the value goes 100 -> 101 -> 100 -> 102. The dip to 100 looks like a real price movement but is just the second read hitting a stale follower.

Implementation: pin a session to a single follower (sticky routing) or track the last-seen timestamp.

Monotonic Writes

Guarantee: writes from the same client are applied in the order issued.

Why you need it: a user clicks 'add to cart' for items A, B, C in order. Without monotonic writes, the cart might end up with A, C, B - or worse, missing one because writes were applied out of order and one was discarded.

Implementation: serialize per-session writes, often by routing all writes from a session through the same partition.

Writes-Follow-Reads

Guarantee: a write that happens after a read sees the value of (or later than) what was read.

Why you need it: a user reads an old comment, replies to it, and the reply must be visible to others as an answer to the original (not appear before it).

Decision Matrix

Implementation Patterns

Pattern: read-your-writes via session token

The client holds a token (last-write-timestamp or vector clock) returned by the database. On the next read, the client sends the token; the database routes the read to a replica that has caught up to it.

async function updateProfile(userId, patch) {
    const result = await db.write({ table: 'profiles', id: userId, patch });
    sessionStorage.setItem('profileToken', result.commitToken);
    return result;
}

async function readProfile(userId) {
    const token = sessionStorage.getItem('profileToken');
    return await db.read({
        table: 'profiles',
        id: userId,
        atLeast: token, // server picks a replica caught up to this token
    });
}

Pattern: causal consistency via vector clocks

Each write is tagged with a vector clock. When a client reads, it observes the vector clock of the read. When the same client writes next, it includes the read clock as a 'happens-after' constraint. The server only commits if all causally-prior writes are present on the replica.

MongoDB does this automatically via causal-consistency sessions: client.startSession({causalConsistency: true}).

Pattern: tunable consistency in Cassandra

Cassandra exposes consistency as a per-request parameter. With N=3 replicas:

-- Strong (linearizable for the key): R + W > N
UPDATE users USING CONSISTENCY QUORUM SET name = 'Bob' WHERE id = 1;
SELECT name FROM users USING CONSISTENCY QUORUM WHERE id = 1;

-- Eventual (fast): R = W = ONE
UPDATE users USING CONSISTENCY ONE SET name = 'Bob' WHERE id = 1;
SELECT name FROM users USING CONSISTENCY ONE WHERE id = 1;

How Real Systems Advertise Consistency

How to Talk About This in an Interview

1. Pick the model first, then justify. 'For the chat system I would use causal consistency, because the requirement is that replies appear after their parent message; cross-conversation ordering does not matter.'
2. Mention the cost. 'Strong consistency would solve the same problem but at higher latency and lower availability during partitions, which is overkill here.'
3. Name the implementation primitive. 'I would use vector clocks or rely on MongoDB causal sessions.'
4. Distinguish per-feature consistency. 'Within the same product, billing uses strict serializability, the user feed uses causal, and the recommendation widget uses eventual. Mixing models is the right answer.'
5. Acknowledge session guarantees as the practical default. 'For most user-facing flows, read-your-writes plus monotonic reads is enough. Full linearizability is rarely needed and rarely worth the latency.'

Quick Review

• Linearizability: every op happens at a single moment; everyone agrees in real-time order.
• Strict serializability: linearizable + serializable transactions.
• Causal: causally-related ops are ordered; unrelated ops are not.
• Eventual: replicas converge in the absence of writes; no other guarantees.
• Session guarantees (read-your-writes, monotonic reads, monotonic writes) cover most user-facing needs cheaply.
• Pick the weakest model the user can tolerate; you pay in latency and availability for stronger.