beginnerintermediateadvanced

System Design · Section 40

Consistency Models

Level: advanced
Read: 20 min
Concepts: 3

Four named consistency models sit on a strength spectrum, each relaxing a different guarantee: strong consistency (every read sees the latest write), causal consistency (causally related writes stay ordered for everyone, unrelated ones do not), read-your-writes (a single process always sees its own prior writes), and eventual consistency (all copies converge given enough time, with no promise about what a read sees before that). A stronger guarantee always costs more coordination — higher latency, and reduced availability under certain failures — which is the real, deliberate trade-off every distributed store makes, and the direct motivation for the CAP theorem covered fully in the next section. CAP itself is most useful treated as a reasoning framework — asking what a specific operation actually does during an actual network partition — rather than reduced to a one-word system label that predicts nothing concrete about real behavior.

This section

Consistency Models | System Design | Distributed SystemsKnowledge Center

What is true here

Four named models, strongest to weakest: strong, causal, read-your-writes, eventual — each relaxes a different guarantee for performance or availability.
Stronger consistency requires more coordination between nodes, which costs latency and can cost availability under certain failure conditions.
A real system rarely makes one consistency choice for everything — different operations often genuinely need different guarantees.
CAP is most useful as a set of concrete questions about a specific operation during an actual partition, not a one-word label applied to a whole system.

What you will be able to do

Distinguish the four named consistency models and rank them by strength
Explain the coordination cost behind a stronger consistency guarantee
Reason through what a specific operation actually does during a network partition, rather than reciting a system-wide CAP label

The four models, and what stronger guarantees cost

The four named consistency models ranked by strength, and the real coordination cost each stronger guarantee requires.

Strong, eventual, causal and read-your-writes consistency

coreadvanced

These four named models sit on a spectrum from strictest to loosest, each relaxing a different guarantee in exchange for better performance or availability. Strong consistency means every read sees the most recent write, as if there were only one copy of the data. Eventual consistency only guarantees that, given enough time with no new writes, every copy converges — with no guarantee about what a read sees in the meantime. Causal consistency sits in between: operations that are causally related (a reply to a comment) must be seen in that same order by everyone, but truly concurrent, unrelated writes can be seen in different orders by different observers. Read-your-writes is a narrower, single-user guarantee: whatever a specific process just wrote, that same process will see on its own next read — even if other processes have not caught up yet.

Think of it as

Think of four different standards for how quickly news spreads through a large organization. Strong consistency is a single company-wide announcement system where everyone hears the news at the exact same instant — nobody can ever be "ahead" or "behind." Eventual consistency is word-of-mouth gossip — it will eventually reach everyone, but at any given moment some people know and some do not, with no promise about who finds out first. Causal consistency is like a chain of replies in a group chat — if someone replies to a message, everyone who sees the reply also has to have seen the original message first (cause before effect), even though two unrelated side conversations can appear in either order to different readers. Read-your-writes is the guarantee that you, personally, always remember what you yourself just said — even if the rest of the group has not caught up on it yet.

What we're doing: Show the same comment-and-reply scenario under causal consistency vs eventual consistency, illustrating exactly what causal ordering adds.

causal-vs-eventual.txttext

User A posts: "What's for lunch?"
User B replies: "Pizza!" (causally AFTER A's post
                  — B read A's post before replying)

Under EVENTUAL consistency alone:
  A different user, C, reading from a lagging
  replica, could see B's reply ("Pizza!") appear
  BEFORE A's original question ever shows up —
  a reply to a question that, from C's view,
  hasn't been asked yet. Confusing, but allowed,
  because eventual consistency makes no ordering
  promise at all before convergence.

Under CAUSAL consistency:
  The system tracks that B's reply causally
  depends on having seen A's post. C is
  GUARANTEED to see A's question before B's
  reply, in that order, every time — even if C
  is reading from a lagging replica. Two
  genuinely UNRELATED posts from other users,
  with no causal link between them, could still
  appear in either order to C — only the
  causally-linked pair has an ordering guarantee.

9: This is the specific confusing case eventual consistency alone allows — cause and effect appearing out of order to some observer.
19: This is exactly what causal consistency adds on top of plain eventual consistency — the specific causally-linked pair is now guaranteed ordered, without paying for full strong consistency on every unrelated write too.

Why this works: This is the concrete value causal consistency provides over plain eventual consistency — it fixes the specific class of confusing "effect before cause" anomalies users actually notice, without paying strong consistency's full coordination cost on every single write in the system, most of which are not causally related to each other at all.

Assuming "read-your-writes" implies other users also see your write promptly

Wrong

text

"Our system guarantees read-your-writes, so
after I post a comment, everyone viewing this
page will see it too, right away."

Better

text

"Read-your-writes only guarantees that I,
personally, will see my own comment on my next
read — it says nothing about when other users
see it. If everyone needs to see new comments
promptly, that's a different, stronger
requirement (closer to strong or causal
consistency for that specific data), not
something read-your-writes provides on its own."

What you see: A feature built assuming read-your-writes covers "everyone sees updates quickly" works fine for the user who just posted (they see their own comment instantly) but other users still see a stale page for a while — the guarantee that was actually configured only ever covered the posting user's own subsequent reads, not anyone else's.

Why: Read-your-writes is explicitly a single-process (or single-session) guarantee — it says nothing at all about what any OTHER process observes, which is a fundamentally different and much weaker promise than "the write becomes visible to everyone quickly," and conflating the two leads to a feature that only half-works.

Four models, strictest to loosest

Strong

every read sees the latest write

Causal

related writes stay ordered

Read-your-writes

you always see your own writes

Eventual

converges, no ordering promise

The four models compared directly

The four models compared directly
Model	Guarantee	What it does NOT guarantee
Strong	Every read sees the latest write, system-wide	Free — real coordination cost, often reduced availability
Causal	Causally related writes seen in the same order by everyone	Ordering between genuinely unrelated concurrent writes
Read-your-writes	A process always sees its own prior writes	Other processes seeing that same write at all, or in any particular order
Eventual	All copies converge once writes stop	Anything about what a read sees before that convergence

Remember: Strong > causal > read-your-writes > eventual, from strictest to loosest. Strong: every read sees the latest write. Causal: causally-related writes stay ordered for everyone, unrelated ones do not. Read-your-writes: a single process always sees its own prior writes. Eventual: all copies converge eventually, with no promise about anything before that.

Distributed stores trade consistency, availability and partition tolerance differently

standardadvanced

Different distributed data stores make genuinely different design choices about which of the four consistency models to offer, and those choices are not free — each one trades away something else (usually availability under certain failure conditions, or write/read latency) to provide a stronger consistency guarantee. A store built for strong consistency has to coordinate across nodes before confirming a write, which costs latency and can mean refusing an operation entirely if enough nodes are unreachable. A store built for eventual consistency can stay available and fast almost no matter what, because it never has to wait for that coordination — the cost is the staleness window covered by eventual consistency itself. This trade-off is the direct motivation for the CAP theorem, covered in full in the next section.

Think of it as

Picture two different policies for a shared team decision that needs everyone's sign-off versus a policy where anyone can act unilaterally and the team reconciles afterward. The sign-off policy guarantees the whole team is always in agreement before anything happens — but if even one team member is unreachable (on a plane, phone off), the decision simply cannot proceed at all until they are reachable again. The act-unilaterally policy means someone can always make progress immediately, with no coordination delay — but it accepts that two team members might briefly make conflicting decisions before anyone notices and reconciles them. Neither policy is objectively better; they are different, deliberate trades between "always in agreement, sometimes cannot act" and "can always act, sometimes briefly disagrees."

text

stronger consistency  <->  more coordination
                            <->  higher latency
                            <->  lower availability
                                 under some failures

weaker consistency     <->  less coordination
                            <->  lower latency
                            <->  higher availability

What we're doing: Show the same write operation behaving differently under a strong-consistency store vs an eventually-consistent store when a coordinating node becomes unreachable.

coordination-under-failure.txttext

A 3-node cluster; one node becomes unreachable
due to a network issue.

Strong-consistency store (requires majority
acknowledgment before confirming a write):
  A write needs 2 of 3 nodes to acknowledge.
  With 1 node unreachable, 2 are still reachable
  -- the write can still succeed, but at the cost
  of waiting for that 2-node coordination round
  trip every single time, even under normal
  conditions with no failures at all.

Eventually-consistent store (any single
reachable node can accept a write immediately):
  The write succeeds against whichever node
  received it, immediately, with no coordination
  wait -- the unreachable node simply catches up
  later once it reconnects. Faster in the normal
  case, and the write still succeeds even under
  this partial failure, at the cost of the
  now-familiar staleness window on the node that's
  behind.

9: This coordination cost is paid on EVERY write, not just during failures — that is the real, ongoing price of the stronger guarantee.
20: This is the trade taken instead — availability and speed are preserved, but at the cost of exactly the staleness this whole topic has already covered.

Why this works: This is the concrete version of the trade-off — the same underlying write operation, same cluster, same partial failure, genuinely different outcomes depending on which consistency guarantee the store was built to provide.

Same write, one node unreachable

Strong consistency

+Needs 2 of 3 nodes to acknowledge
+Write still succeeds, but pays a coordination round trip
+That cost is paid on every write, not just during failures

Eventual consistency

−Any reachable node accepts the write immediately
−The unreachable node catches up later
−Faster always, at the cost of a staleness window

The general shape of the trade-off, by consistency model

The general shape of the trade-off, by consistency model
Consistency level	Typical latency cost	Typical availability cost
Strong	Higher — real coordination required before confirming	Can refuse an operation if coordination cannot complete
Causal	Moderate — coordination only for causally related writes	Generally available except for the specific causal chain affected
Read-your-writes	Low for the writing process's own reads	High — mostly unaffected by other nodes' state
Eventual	Lowest — no coordination wait at all	Highest — a node can respond even if fully isolated from others

Remember: Stronger consistency costs more coordination, which costs latency and can cost availability under certain failures; weaker consistency avoids that coordination cost, at the price of the staleness or ordering guarantees given up. This is a deliberate, real trade-off made per store (or per operation) — not a flaw to be engineered away, and the direct motivation for the CAP theorem covered next.

CAP as a design tool

Using CAP to ask concrete questions about a specific operation's behavior during a partition, rather than reducing a system to a single label.

CAP as a reasoning framework, not a slogan

coreadvanced

The CAP theorem is most useful not as a fact to recite ("consistency, availability, partition tolerance — pick two") but as a set of questions to actually ask about a specific system: what happens to THIS store, for THIS operation, specifically during a network partition? Treated as a slogan, CAP becomes a shallow label ("we're a CP system") that explains nothing about actual behavior. Treated as a reasoning framework, it becomes a genuinely useful tool for predicting and designing what a system does under a concrete failure — which nodes can still serve which operations, what a client sees, and what the recovery looks like once the partition heals.

Think of it as

Compare labeling a car "safe" versus actually asking what happens in a specific kind of collision. The label "safe" tells you almost nothing useful — you cannot design a real safety plan around one word. But asking "what specifically happens in a rear-end collision at 30mph" gives you an actual, concrete, useful answer you can plan around. CAP used as a slogan ("we're AP") is the one-word label. CAP used as a reasoning framework means asking the concrete question — "during a network partition between our two regions, does a write to Region A wait for Region B, fail, or succeed independently and reconcile later?" — which is the question that actually predicts what users experience.

What we're doing: Walk through applying CAP as a reasoning framework to a concrete design question, contrasting with the shallow slogan-only answer.

cap-as-questions.txttext

Design question: "Our shopping cart service
replicates across 2 regions. What happens if the
network link between regions goes down?"

Slogan-only answer:
  "We're an AP system, so we stay available."
  -- True, but tells the engineering team almost
     nothing about what to actually build or what
     to tell users.

Reasoning-framework answer:
  "During the partition, each region accepts
  cart writes independently (available on both
  sides). If a user's cart is modified in BOTH
  regions during the partition (e.g. they travel
  and their requests land on different regions),
  we need an explicit merge strategy once the
  partition heals -- e.g. union the two carts'
  items rather than picking one arbitrarily. We
  also need to decide: does the UI show any
  indication that the cart might be 'still
  syncing' during and immediately after a
  partition, or do we hide that entirely?"

6: This is the slogan-only version — technically correct, but it answers nothing an engineer could actually build from.
12: This is the same fact, reasoned through concretely — it surfaces a real design requirement (a merge strategy) the slogan alone never revealed.

Why this works: This is the practical payoff of treating CAP as a framework rather than a label — the concrete walkthrough surfaces an actual engineering requirement (how to merge conflicting cart states) that "we're AP" alone never would have prompted anyone to design for.

Choosing a database based on its CAP label alone, without reasoning through the specific operations that matter for the actual workload

Wrong

text

"We need availability, so we should use an AP
database — that's what the label says to pick."

Better

text

"We need availability for browsing and adding
items to a cart, but strong consistency for the
final checkout/payment step. A single database's
CAP label describes its DEFAULT behavior, not
necessarily every operation we need — we should
check whether it lets us tune consistency per
operation, or whether we need two different
stores for the two different needs."

What you see: A database chosen purely because its marketing or documentation labels it "AP" turns out not to offer the specific consistency guarantee a critical operation (like payment processing) actually needs, forcing an awkward workaround or a second database — a decision that reasoning through the actual per-operation requirements up front would have caught before the database was ever chosen.

Why: A CAP label describes a system's general default posture, not a guarantee about every operation it will ever be asked to perform — treating the label as sufficient due diligence skips the actual reasoning step (what does THIS specific critical operation need) that the label was never meant to substitute for.

CAP as a slogan vs. as a reasoning framework

Slogan ("we're AP")

+A single label applied to a whole system
+Technically true, predicts nothing specific
+Does not surface real design requirements

Reasoning framework

−Concrete answer for THIS operation, THIS partition
−Directly informs what to build
−Surfaces requirements the label alone would miss

CAP as a slogan vs CAP as a reasoning framework

CAP as a slogan vs CAP as a reasoning framework
Approach	What it produces	Usefulness for actual design
Slogan ("pick 2 of 3")	A single label applied to a whole system	Low — does not predict specific operation behavior
Reasoning framework	Concrete answers to "what happens to THIS operation during a partition?"	High — directly informs what to build and what to tell users

Remember: Use CAP to ask concrete questions about a specific operation during an actual partition — what does it do, what does the caller see, how does it reconcile afterward — rather than reducing a whole system to a one-word label. The label describes a general default; the reasoning is what actually predicts behavior and informs what to build.