distributed-systems · intermediate

Consistency Models — From Strong to Eventual

Start here

A consistency model is a rulebook for what clients may observe.

When many users read and write, and when data has multiple copies, the system must answer questions like:

• Can I see a write before it is fully committed everywhere?
• Can two users see different orders of events?
• If I read twice, can time go backward?

This lesson is progressive. You do not need a PhD. We will climb from everyday ideas to a few standard names used in real systems.

What you will learn

1. Explain what a consistency model is protecting.
2. Place models on a rough spectrum from strong to weak.
3. Define linearizability and serializability in plain language (and how they differ).
4. Define sequential, causal, and eventual consistency at a usable level.
5. Connect models to CAP, latency, and multi-region design.
6. Pick models per data class with a worked social + payments example.
7. Know what to study next (quorums, transactions).

What you should know first

Words you need before we begin

Simple story: the group chat timeline

Four friends message in a chat.

• Strong order everyone shares: all phones show the exact same global order of messages, updating live. Hard when phones are offline.
• Causal order: if you reply to a message, nobody sees the reply before the original.
• Eventual: while offline, phones diverge; when online again, messages sync and settle.

Where the analogy stops: databases formalize these ideas with math; apps also have UI rules (“sending…” state) that are not the store’s model.

The problem: concurrency makes “obvious” order unclear

On one single-threaded program, operations happen in a clear sequence.

In a distributed system:

• Client A writes x = 1
• Client B writes x = 2 at “about the same time”
• Client C reads

Step-by-step explanation

Step 1 — Models are contracts, not vibes

When a vendor says “strongly consistent reads,” ask:

• Consistent with what model?
• Across which keys / transactions?
• With what failure behavior?

Step 2 — A simple spectrum (not perfect, but useful)

From stronger / more coordinated → weaker / more scalable (roughly):

1. Linearizability (per object, real-time)
2. Sequential consistency
3. Causal consistency
4. Session guarantees (read-your-writes, monotonic reads)
5. Eventual consistency

Step 3 — Linearizability (plain English)

Linearizability means each operation on an object appears to take effect instantly at some point between its start and end, and all clients agree on that order, respecting real-time order when operations do not overlap.

Intuition:

• There is one global up-to-date object.
• Once a write completes, any read that starts later sees it (or a newer write).

Step 4 — Serializability (plain English)

Serializability applies to transactions (bundles of operations):

The result looks as if transactions ran one after another in some order — not interleaved in a messy way that breaks application invariants.

Example invariant: “transfer money: debit A and credit B together.” Serializability helps such multi-step logic appear atomic as a group.

Note: a system can be serializable yet allow behaviors that linearizability would forbid, depending on timing details. You do not need the edge cases on day one — remember transactions vs single operations.

Step 5 — Sequential consistency

Sequential consistency says there is a single global order of operations that all clients agree on, and each client’s own operations appear in the order it issued them — but that global order does not have to respect real-time as strictly as linearizability.

Intuition: everyone agrees on a story order, but the story may rearrange overlapping real-time operations more freely than linearizability allows.

Step 6 — Causal consistency

Causal consistency preserves cause and effect:

• If you write B after reading A (or otherwise depending on A), then anyone who sees B must be able to see A first.
• Concurrent writes with no causal link may be seen in different orders by different clients.

Step 7 — Session guarantees (practical everyday tools)

Even under weaker global models, systems often try to provide:

These make UX saner without global strong consistency.

Step 8 — Eventual consistency revisited

Eventual consistency allows temporary disagreement. If updates stop, replicas converge.

It is the weakest common product term — and the most misused. Always ask about:

• Conflict resolution
• Typical lag
• Session guarantees
• Whether deletes can resurrect (surprising under some designs)

Step 9 — How to choose (beginner decision guide)

Ask:

1. Multi-key business invariant? Lean toward transactional serializability (or careful workflows).
2. Single key, must never look stale after success? Lean linearizable / strong primary reads.
3. Collaborative / social / multi-region chatty data? Causal or session + eventual may fit.
4. Can you show “updating…” UI? Weaker models become acceptable.
5. What is the merge story? If you cannot merge, do not allow concurrent multi-writer updates.

Visual mental model

Spectrum

flowchart LR
  L[Linearizability] --> S[Sequential]
  S --> C[Causal]
  C --> G[Session guarantees]
  G --> E[Eventual]

Learning question: Which direction usually needs more coordination?

Caption: Left = stronger, more coordination; right = weaker, more scale flexibility.

Transactions vs single ops

flowchart TB
  subgraph ops [Single operations]
    Lin[Linearizability]
  end
  subgraph tx [Transactions]
    Ser[Serializability]
  end
  App[Application invariants] --> tx
  App --> ops

Learning question: Which box helps “debit + credit as one unit” most directly?

Caption: Multi-key atomic logic → transactions/serializability family.

Complete worked example: social app + wallet

Product pieces

1. User bio text
2. Follow graph
3. Feed posts
4. Wallet balance for tips

Model choices

Partition behavior notes

• Bio: both regions may accept edits; last-write-wins or field-level merge.
• Wallet: majority quorum or single primary; minority refuses spends.

Outcome

The app is not “one consistency model.” It is a portfolio of models. That is normal and healthy.

How it works in production

Where models show up in tools

• Dynamo-style stores: tunable quorums, often eventual by default
• etcd / ZooKeeper / Consul: linearizable ops for coordination
• Relational DBs: isolation levels (Read Committed, Snapshot, Serializable)
• Distributed SQL: vary by product

Testing consistency assumptions

• Jepsen-style tests (advanced)
• Application-level assertions under fault injection
• Chaos for partitions

Documentation duty

Write down for each critical data type:

• Intended model
• Acceptable staleness
• Conflict policy

Failure modes

Trade-offs

Compare with related concepts

Common misunderstandings

1. “Serializable means linearizable.”

1. “Eventual will fix itself in N seconds.”

1. “More replicas make consistency stronger.”

1. “We use Kubernetes so we are linearizable.”

1. “Weak models are unprofessional.”

Check your understanding

Serializability

Eventual consistency only

Bandwidth consistency

TTL consistency

Causal consistency

Unconditional eventual with no ordering

RAID-0 only

Random consistency

Practice

For an online classroom product:

1. Assign a model leaning to: grades, course title, live quiz answers, student notes drafts.
2. For grades, write one invariant that serializable transactions would protect.
3. For notes drafts, describe a conflict when two devices edit offline.
4. List two session guarantees that would improve notes UX.
5. Explain how a partition between regions should treat grade submission vs draft sync differently.

Revision summary

1. Consistency models = allowed observation rules.
2. Stronger models coordinate more; weaker models scale more easily.
3. Linearizability ≈ single-copy real-time object behavior.
4. Serializability ≈ transactions as one-at-a-time.
5. Causal and session guarantees are practical middle layers.
6. Eventual needs merge policy and lag metrics.
7. Choose per data, not per logo.

Glossary

Abbreviations and terminology

What to learn next

Primary next lesson: Quorum reads vs quorum writes

Also useful: data replication and ACID/transaction lessons when you implement multi-key invariants.

Track: Distributed Systems

Previous: CAP, Consistency & Idempotency

Next: Strong vs Eventual Consistency — Trade-offs in Distributed Systems

Series: CAP, Consistency & Quorums

1. CAP Theorem — Consistency, Availability, and Partition Tolerance
2. Consistency Models — From Strong to Eventual (this guide)
3. Strong vs Eventual Consistency — Trade-offs in Distributed Systems
4. CAP, Consistency & Idempotency
5. Quorum Reads vs Quorum Writes

All series

By Shubham Jain

All articles · Study paths

Shubham Jain · Learning Lab