Consistency Models

Four named guarantees, what each one costs, and using CAP as a question, not a label

Four modelsstrong > causal > read-your-writes > eventual
Real trade-offstronger consistency costs coordination and latency
CAP as questionswhat does THIS operation do during a partition?
Mixed in practicedifferent operations, different guarantees

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

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.

Key features

Strong consistency: every read reflects the most recent completed write, system-wide — the strictest and most expensive guarantee, requiring real coordination between nodes
Eventual consistency: given enough time with no new writes, all copies converge to the same value — makes no promise about what any given read sees before that convergence happens
Causal consistency: writes that are causally related (one happened because of, or after seeing, another) must be observed in that same order by every process; concurrent, unrelated writes have no ordering guarantee between them
Read-your-writes (a specific session guarantee, sometimes generalized as "session consistency"): a single process is always guaranteed to see its own prior writes on its own subsequent reads, regardless of what any other process currently observes
These form a rough strength hierarchy from strictest to loosest: strong > causal > read-your-writes > eventual (with eventual consistency being the weakest, since it makes no promise at all about ordering or freshness before convergence, only that convergence eventually happens)

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

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

Signature

strong > causal > read-your-writes > eventual — each relaxes a different guarantee for performance/availability

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.

2.Distributed stores trade consistency, availability and partition tolerance differently

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.

Key features

A stronger consistency guarantee generally requires more coordination between nodes before confirming an operation, which costs latency and can reduce availability specifically when that coordination cannot complete (e.g. some nodes are unreachable)
A weaker consistency guarantee generally allows a node to respond immediately without waiting for coordination, which improves latency and availability at the cost of the staleness or ordering guarantees the weaker model gives up
This is a genuine, deliberate design choice made per data store (and sometimes per operation within a store) — it is not a limitation to be "fixed," it is a real trade-off with no universally correct answer
Real systems often mix models — e.g. a store might offer strong consistency for single-key operations but only eventual consistency for cross-key or cross-region reads, matching the guarantee to what each specific operation actually needs
This trade-off is the direct motivation for the CAP theorem's formal framing of what happens specifically during a network partition — covered in full depth in the next section rather than repeated here

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

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

Command

text

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

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

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.

3.CAP as a reasoning framework, not a slogan

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.

Key features

As a slogan, "CAP" gets reduced to a single label per system ("we're a CP database" or "we're an AP database"), which flattens a genuinely nuanced, per-operation reality into one word that does not actually describe specific behavior
As a reasoning framework, CAP prompts concrete questions: during a partition, does this specific operation block waiting for the other side, fail outright, or proceed independently on both sides and reconcile afterward?
A single real system is rarely purely CP or purely AP for everything it does — different operations, or even the same operation under different configuration, can make different choices, which a one-word label cannot capture but the underlying reasoning can
The reasoning framework extends naturally to the next question this project's own PACELC concept (already shipped) covers — what does the SAME system trade off even when there is no partition at all, just normal latency vs consistency pressure
Using CAP as a design tool means walking through the actual partition scenario for a specific system before building it — not adopting a label after the fact and assuming it fully describes behavior

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

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

Signature

ask "what does THIS operation do during an actual partition?" — not "what's our one-word CAP label?"

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.

Spotted a mistake on this page? Tell us.

Read Sheet