The CAP lesson established that once data lives on more than one machine, a network partition forces you to choose between consistency and availability.
That framing is binary, and reality is not. Between "every read sees the latest write" and "reads may return anything recent" sits a spectrum of useful guarantees — and knowing them is what lets you pick something appropriate rather than defaulting to the extremes.
Strong consistency
Every read returns the most recent write. The system behaves as though there is exactly one copy of the data, regardless of how many machines actually hold it.
This is what a single database gives you for free, and what a distributed system must work hard for.
The cost is time. To guarantee a read is current, the nodes must agree, and agreement requires network round trips. Every read or write waits for coordination — so strong consistency means higher latency, always, and unavailability during a partition.
Use it where being wrong is unacceptable: account balances, inventory for scarce goods, unique username registration, anything where two parties must not both win.
Eventual consistency
If writes stop, all replicas converge on the same value. Until then, reads may return stale data.
The benefit is speed and availability. Any replica can answer immediately without consulting anyone.
The word "eventually" typically means milliseconds. But note carefully: eventual consistency makes no promise about what you see in the meantime. Two consecutive reads can return different values, and — surprisingly — values can appear to move backwards.
That last part is why the middle of the spectrum exists.
The session guarantees
These are the practically useful ones, because they fix specific user-visible weirdness without paying for full strong consistency.
Read-your-own-writes
You always see your own updates. Others may lag.
Without it you get the bug from the replication lesson: a user saves their profile, the reload hits a lagging replica, they see the old value and conclude the save failed.
This is the single most important guarantee for user-facing systems, and it is cheap — route a user's reads to the leader briefly after they write.
Monotonic reads
Once you have seen a value, you never see an older one.
Without it, refreshing can hit a replica further behind and data appears to travel backwards — a comment you just saw vanishes. Fixed by pinning each user to one replica.
Consistent prefix
If writes happened in an order, you see them in that order — never effects before causes.
The classic failure is a chat where you see the reply before the question:
Amit: "Shall we ship it?"
Priya: "Yes, do it."arriving as "Yes, do it." then "Shall we ship it?". Nothing is lost; the order is wrong, and the conversation is nonsense.
Causal consistency
A step further: operations that are causally related are seen in order by everyone, while unrelated operations may be seen in any order.
If a comment replies to a post, everyone sees the post first. Two unrelated posts may appear in different orders to different users, and nobody cares.
This is close to the strongest guarantee achievable while remaining available during a partition, which makes it a genuinely useful ceiling to know about.
Quorums: the tunable dial
Leaderless systems such as Cassandra and DynamoDB let you choose consistency per query using three numbers:
- N — how many replicas hold the data
- W — how many must acknowledge a write
- R — how many must respond to a read
The rule that matters:
If W + R > N, the read and write sets must overlap, so at least one node you read from has the latest write.
With N = 3:
| W | R | Meaning |
|---|---|---|
| 3 | 1 | Slow writes, fast reads, strongly consistent |
| 1 | 3 | Fast writes, slow reads, strongly consistent |
| 2 | 2 | Balanced, strongly consistent (2+2 > 3) |
| 1 | 1 | Fastest, eventually consistent (1+1 is not > 3) |
The insight worth carrying: you are not choosing a database's consistency, you are choosing it per operation. The same table can serve a fast, possibly-stale read for a product listing and a quorum read at checkout.
Choosing in practice
Diagram, as text
- Strong: every read sees the last write leads to Causal: effects follow causes
- Causal: effects follow causes leads to Session: your own writes, monotonic reads
- Session: your own writes, monotonic reads leads to Eventual: copies converge if writes stop
- Strong: every read sees the last write leads to Eventual: copies converge if writes stop (more coordination, more latency)
Ask what a stale read actually causes.
| Data | Staleness cost | Choose |
|---|---|---|
| Bank balance | Overdraft, fraud | Strong |
| Inventory (last item) | Overselling | Strong |
| Username availability | Duplicate accounts | Strong |
| Social feed | Post appears late | Eventual |
| View or like counts | Number slightly off | Eventual |
| Product description | Briefly outdated text | Eventual |
| User's own profile | Looks like save failed | Eventual + read-your-writes |
The last row is the pattern worth internalising: most user-facing data is fine eventually consistent provided the user sees their own actions immediately.
Conflict resolution
When multiple nodes accept writes, two can modify the same value simultaneously. Something must decide.
Last write wins — keep the one with the highest timestamp. Simple, and it silently discards data. It also depends on synchronised clocks, which across machines is a genuinely unreliable assumption.
Application-level merge — keep both versions and let the application decide. A shopping cart can union both sets of items, so nothing is lost even if a removed item reappears.
CRDTs — data structures mathematically designed so concurrent updates always merge to the same result. A counter that only increments, or a set that only grows, can be merged without coordination. This is what makes collaborative editing work.
Check your understanding
Common mistakes
Applying one choice system-wide. Consistency is per operation. The same product is eventual for browsing and strong at checkout.
Assuming strong consistency by default. Adding a read replica silently makes reads eventually consistent. Code written against a single database may quietly break.
Ignoring clock skew. Last-write-wins depends on timestamps from different machines, whose clocks drift. Logical clocks or version vectors are safer.
Confusing consistency with durability. A write can be durable — safely stored — and still not visible everywhere yet. Different properties.
Practice
Design the consistency requirements for a collaborative document editor: text edits, the cursor positions of collaborators, the document title, and the sharing permissions. State what each needs and why.
Write your own answer first, on paper or in a note. Then compare.
Show a hint
For each, ask what a user would notice if two people saw different values for a second.
Show a strong answer
- Text edits — causal consistency, converging. Edits must apply in an order that respects causality: if B edits a sentence A just typed, nobody may see B's edit without A's. Full strong consistency would mean coordinating on every keystroke and is unusable at typing latency. This is why editors use structures that converge regardless of arrival order while preserving causal order.
- Cursor positions — no guarantee at all. These are ephemeral. A cursor 300 ms stale is fine; a cursor delayed to preserve ordering is worse than one that is slightly wrong. Send them on a best-effort path and drop them under load.
- Document title — eventual, with last-write-wins. Two people renaming simultaneously is rare, and the loser can rename again. Paying for coordination here buys almost nothing.
- Sharing permissions — strong consistency, without exception. This is the one that must not be eventual. If revoking someone's access is eventually consistent, there is a window in which a removed collaborator can still read the document — and the whole point of revocation is that the window does not exist. Permissions checks must read from a source that cannot be stale.
The shape to notice: three of the four are fine with weak guarantees, and the fourth is a security boundary. Consistency requirements follow consequences, not data types.
Your team runs N=3, W=1, R=1 for speed. Describe concretely what can go wrong, and what you would change if the data were account balances.
Write your own answer first, on paper or in a note. Then compare.
Show a hint
Add W and R and compare with N.
Show a strong answer
W + R = 2, which is not greater than N = 3, so the read set and write set need not overlap at all. Concretely:
- A write succeeds after reaching one replica. It is acknowledged to the client.
- A read is served by one replica, which may be either of the other two.
- The reader therefore sees the old value, with no error and no indication anything is stale. This is not a rare race — it is the expected behaviour roughly two times in three immediately after a write.
- Worse, if the single replica holding the write dies before it propagates, the acknowledged write is lost entirely and nothing ever reports it.
For account balances this is unusable. The failure is not "a slightly stale number"; it is a balance that is wrong at the moment a withdrawal is authorised, and an acknowledged deposit that can vanish.
What I would change:
- W=2, R=2 at minimum, so the sets overlap and an acknowledged write survives one replica failing. Latency rises to the second-fastest replica on both paths — the honest cost.
- Better, for money: do not use quorums at all. Balances need atomic read-modify-write, and a quorum gives you a value, not a transaction. Two concurrent withdrawals can each read the same balance and each succeed. Use a store with real transactions on this path, and keep the quorum store for data where converging later is acceptable.
The general point: quorums tune staleness, not atomicity. No W and R setting makes a lost update impossible.
Key takeaways
- Between strong and eventual lies a spectrum, and the middle is usually the right place to be.
- The session guarantees — read-your-own-writes, monotonic reads, consistent prefix — fix specific user-visible weirdness cheaply.
- Read-your-own-writes is the most valuable for user-facing systems: users forgive stale data about others, never about themselves.
- Causal consistency preserves cause-and-effect ordering and is roughly the strongest guarantee compatible with staying available.
- With quorums, W + R > N gives strong consistency, and the dial is set per query, not per database.
- Choose by asking what a stale read actually causes — and remember eventual consistency is a precise convergence property, not permission to be wrong.
Further reading
- Werner Vogels, "Eventually Consistent" (ACM Queue, 2008) — the vocabulary of session guarantees.
- Douglas Terry et al., "Session Guarantees for Weakly Consistent Replicated Data" (PDIS 1994) — where read-your-writes and monotonic reads were defined.
- Maurice Herlihy and Jeannette Wing, "Linearizability: A Correctness Condition for Concurrent Objects" (ACM TOPLAS, 1990) — what strong consistency formally means.
- Peter Bailis et al., "Probabilistically Bounded Staleness for Practical Partial Quorums" (VLDB 2012) — how stale eventual reads actually are.
- Marc Shapiro et al., "Conflict-free Replicated Data Types" (SSS 2011) — convergence without coordination.