Module 06 // Reliability and trade-offsLesson 21 / 3416 min read
Consistency models
A consistency model is the promise a system makes about what you'll see when you read data that's being changed, from "always the latest" (strong) to "eventually the same everywhere" (eventual), with useful promises in between.
Think of it like this
Analogy
Imagine a team sharing news by word of mouth. With strong consistency, nobody may speak until everyone has heard the news, so nobody ever repeats old information, but it's slow. With eventual consistency, news spreads person to person; for a while some people have the old version, but given a little time everyone catches up.
In between there are softer promises. “You'll always remember what you said yourself” is read-your-writes. “Once you've heard the new version you'll never hear the old one again” is monotonic reads.
The problem it solves
With replication (lesson 11) and caches (lesson 14), the same piece of data exists in several places, updated at slightly different times. Without a clear promise about what readers will see, you get bugs that are hard to reproduce: profiles that revert, counters that go backwards, a user who's charged but sees “unpaid”. Asking for the strongest guarantee everywhere makes the system slow and less available.
A real example
Example
Posting a reply on a busy forum
You post a reply. It's written to the leader database, but page reads come from replicas that are usually a fraction of a second behind.
You refresh, and your reply isn't there. You post it again. Now there are two. That's a missing read-your-writes guarantee.
The forum fixes it simply: for 10 seconds after you write, your own page loads read from the leader. Everyone else keeps reading from replicas and sees your reply a moment later. That's eventual consistency, and for a forum it's fine. Nobody else knows the exact moment you hit post.
How it works
The spectrum, from strongest to weakest
| Model | Promise | Cost |
|---|---|---|
| Strong (linearizable) | Every read sees the latest completed write, everywhere | Slowest; unavailable during partitions |
| Sequential / causal | Everyone sees writes in an order that respects cause and effect (a reply never appears before the message it replies to) | Moderate |
| Read-your-writes | You always see your own changes | Cheap: route your reads carefully |
| Monotonic reads | You never see older data after seeing newer | Cheap: stick to one replica |
| Bounded staleness | Reads are at most N seconds or N versions behind | Tunable |
| Eventual | If writes stop, all copies converge | Fastest and most available |
The middle guarantees are “session” guarantees: they protect one user's experience without forcing the whole system to be strongly consistent.
How systems provide them
- Strong: a single leader that handles all reads and writes for a key, or a consensus protocol (Raft, Paxos) where a majority must agree before a write counts.
- Quorums: with N replicas, wait for W to acknowledge each write and ask R replicas on each read. If W + R is greater than N, every read overlaps at least one replica with the latest write. A common setting is N = 3, W = 2, R = 2.
- Read-your-writes: after a user writes, send their reads to the leader for a short time, or include the write's version and only read from replicas that have caught up to it.
- Monotonic reads: keep each user on the same replica.
- Eventual: async replication, anti-entropy repairs and conflict resolution (lesson 20).
Pick per feature, not per system
| Feature | Model that's usually enough |
|---|---|
| Payments, balances, inventory decrements | Strong |
| Unique usernames, locks, leader election | Strong |
| User editing their own profile or settings | Read-your-writes |
| Chat messages in a conversation | Causal (replies after messages) |
| Feeds, like counts, view counts, search results | Eventual |
| Product catalog, prices shown on listing pages | Bounded staleness, with a strong check at checkout |
Many cloud databases expose this directly: DynamoDB offers eventually or strongly consistent reads per request, and Cosmos DB offers five levels (strong, bounded staleness, session, consistent prefix and eventual), with session as the default.
Trade-offs
What you gain
- Choosing the weakest model that's still correct gives you the best speed and availability.
- Session guarantees remove the most visible weirdness for users at low cost.
- Strong consistency makes the code simpler wherever correctness really matters.
What it costs you
- Strong consistency costs latency (especially across regions) and availability during partitions.
- Eventual consistency pushes complexity into the app: stale reads, conflicts, retries.
- Mixed models are harder to reason about and test.
When not to use it
- Don't pay for strong consistency on data that's fine being seconds old.
- Don't use eventual consistency for anything that guards money, uniqueness or safety.
In the cloud
Replicated and multi-region databasesEvery major cloud sells this as a managed service, so you configure it rather than build it.
AWS2
- Amazon Aurora Global Database (opens vendor docs)
One primary region with read-only copies in other regions, usually under a second behind.
- Amazon DynamoDB global tables (opens vendor docs)
Multi-region, multi-writer tables; replicas converge with last-writer-wins.
Azure2
- Azure Cosmos DB (multi-region) (opens vendor docs)
Replicate to any region, optionally write everywhere, and pick one of five consistency levels.
- Azure SQL Database active geo-replication (opens vendor docs)
Readable secondary databases in other regions with manual or automatic failover.
Google Cloud2
- Spanner (opens vendor docs)
Globally distributed relational database with strong consistency across regions.
- Cloud SQL cross-region read replicas (opens vendor docs)
Read-only copies of a Cloud SQL instance in another region, promotable on disaster.
Writes go to a leader; replicas in other zones or regions serve reads and take over on failure.
- App
- Aurora writer
- Aurora readers
- Secondary region (Global Database)
Interview questions
Try answering out loud first, then open the model answer.
What's the difference between strong and eventual consistency?
Model answer
Strong consistency means that once a write completes, every subsequent read, from anywhere, returns it; the system behaves like one copy. Eventual consistency only promises that if writes stop, all replicas will converge; meanwhile a read may return an older value. Strong costs latency and availability; eventual is fast and available but the app has to tolerate stale data.
Users complain their profile changes seem to revert after saving. Reads come from replicas. How do you fix it without making everything strongly consistent?
Model answer
Provide read-your-writes for the writer. After a user writes, store the write's timestamp or log position in their session, and for the next few seconds either read their data from the leader, or only use replicas that have replicated past that position. Also stick the user to one replica so they don't flip between replicas at different lag (monotonic reads). Other users can keep reading from any replica.
Explain quorum reads and writes.
Model answer
With N replicas, a write is acknowledged once W replicas have it, and a read queries R replicas and takes the newest version. If W + R is greater than N, the read set and write set overlap, so at least one replica in every read has the latest acknowledged write. N = 3, W = 2, R = 2 tolerates one replica down for both reads and writes. Lowering W or R makes operations faster but weakens the guarantee.
Quiz
Pick an answer to see whether it’s right and why.
0 of 6 answered
Key terms
- Strong consistency
- Every read sees the most recent write, as if there were only one copy of the data.
- Eventual consistency
- Copies may disagree for a while, but if writes stop, they all end up the same.
- Read-your-writes
- A guarantee that after you change something, you see your change, even if others don't yet.
- Quorum
- A majority (or set number) of replicas that must agree on a read or write.
- Replication lag
- The delay between a write on the leader and that write appearing on a follower.
Progress is saved in this browser only.