Start practising

SYSTEM DESIGN · CONCEPTS · DISTRIBUTED SYSTEMS · EPISODE 26

Consistency Models: Strong, Eventual, Read-Your-Writes

What a read is allowed to return when data has several copies: strong (linearizable) consistency, eventual consistency, and the session guarantees in between (read-your-writes, monotonic reads, consistent prefix), with the bugs each one prevents and how to pick per feature.

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32
  33. 33
  34. 34
  35. 35
  36. 36
  37. 37
  38. 38
  39. 39
  40. 40
  41. 41
1 / 12

Press play to hear the narration, or step through at your own pace. Every picture here is the same one used in the YouTube video.

Notes

The problem

The setup from episode twenty. You write to the leader; the change is copied to the replicas, but not at the same instant. Replica one has it, replica two is two seconds behind. A read could land on any of them. The consistency model is the rule for what that read may return.

Why it gets hard
  • one write, several copies
  • (episode 20: replication)
  • copies update at different times
  • a read can hit any copy
  • question: which values
  • is a read allowed to see?

Strong

The strongest promise: linearizability, usually just called strong consistency. The system behaves as if there were exactly one copy. Once a write is confirmed, every later read, by anyone, sees it. You get it by reading from the leader or a quorum, and you pay with latency and less availability during failures.

Strong consistency
  • linearizable: as if there
  • were exactly one copy
  • once a write is confirmed,
  • every later read sees it,
  • from anyone, anywhere
  • cost: coordination
  • (leader reads, quorums,
  • consensus) = latency

Eventual

The weakest useful promise: eventual consistency. If writes stop, all copies will converge to the same value. That's it. No promise about when, and no promise about the order you'll see things in. It's cheap and always available, which is why DNS, CDN caches and Cassandra at consistency level one work this way.

Eventual consistency
  • if writes stop, all copies
  • converge to the same value
  • no promise about WHEN
  • and no promise about order
  • cheap and always available
  • DNS, CDN caches, Cassandra
  • at ONE, DynamoDB default reads

In between

Most apps live in between. Strong for everything is too slow; pure eventual produces bugs users notice. So there are session guarantees: promises about what one user sees, which are much cheaper than strong consistency. Three matter in interviews: read your own writes, monotonic reads, and consistent prefix.

The gap in between
  • strong: slow but simple
  • eventual: fast but surprising
  • session guarantees fix the
  • surprises users actually notice:
  • • read your own writes
  • • monotonic reads
  • • consistent prefix

Read your writes

Read your own writes. The bug: you post a comment, reload, and it's gone, because the reload hit a lagging replica. The fix: after a user writes, route their reads to the leader for a few seconds, or have the client send its last write position and only use a replica that has caught up. Other users may still see it a moment later, and that's fine.

Read your own writes
  • bug: post a comment, reload,
  • it is missing (lagging replica)
  • fix: after a write, read from
  • the leader for a few seconds,
  • or send your last-write
  • position and wait for a replica
  • that has caught up
  • others may still see it later

Monotonic reads

Monotonic reads. The bug: you see five comments, refresh, and now there are three, because the second read went to an older replica. Time went backwards. The fix: pin each user to one replica, for example by hashing their user id, or remember the newest version they've seen and never serve them anything older.

Monotonic reads
  • bug: you see 5 comments,
  • refresh, now there are 3
  • (second read hit an older copy)
  • fix: pin each user to one
  • replica (hash the user id),
  • or remember the newest version
  • you have seen and never accept
  • an older one

Consistent prefix

Consistent prefix. The bug: in a chat, you see the reply 'Noon' before the question 'What time is lunch?', because the two messages were stored on different partitions that lag differently. The fix: keep related writes in order, by putting a conversation on one partition or by tracking which write caused which. Causal consistency generalises this.

Consistent prefix
  • bug: you see the answer
  • before the question
  • A: "What time is lunch?"
  • B: "Noon."
  • a reader sees B then A
  • because they were stored on
  • different partitions
  • fix: keep causally related
  • writes in order (same
  • partition, or causal ordering)

The ladder

Put together, it's a ladder. Strong at the top, then causal, then the session guarantees, then eventual at the bottom. Every step up removes a class of surprises and adds coordination, which means latency and less availability during a partition. That's CAP and PACELC from episode twenty-five, seen from the reader's side.

The ladder
  • strong (linearizable)
  • ↓ cheaper, more available
  • causal
  • ↓
  • session guarantees
  • (read-your-writes, monotonic,
  • consistent prefix)
  • ↓
  • eventual

Decision

Choose per feature. Balances, stock counts, unique usernames and locks need strong consistency. Your own profile and posts need read-your-writes. Threads and chat need consistent prefix. Like counts, feeds and search results are fine eventually. One product will use several of these at once.

Pick per feature
  • money, stock, unique usernames,
  • locks → strong
  • your own profile, your own
  • posts → read-your-writes
  • comment threads, chat
  • → consistent prefix / causal
  • like counts, feeds, search
  • → eventual

Say it like this

In the interview, don't just say 'eventually consistent'. Name the model for each feature, the bug it prevents, the mechanism that provides it, like leader reads, quorums, sticky replicas or version tokens, and what it costs. That shows you understand the trade, not just the vocabulary.

In the interview
  • "What consistency do you need?"
  • 1. name the model per feature
  • 2. say what bug it prevents
  • 3. say how: leader reads,
  • quorum, sticky replicas,
  • version tokens
  • 4. say what it costs

Interview questions

What is a consistency model?

A contract between a replicated data store and its clients that defines which values a read may return given the writes that have happened, for example always the latest (strong) or eventually the latest (eventual).

What is strong consistency (linearizability)?

The system behaves as if there were a single copy: once a write completes, every subsequent read by any client returns that value or a newer one. It needs coordination such as leader reads, quorums or consensus, which adds latency.

What does eventual consistency guarantee?

Only that if no new writes arrive, all replicas will eventually converge to the same value. It gives no bound on how long that takes and no ordering guarantee for reads in the meantime.

How do you provide read-your-own-writes?

Route a user’s reads to the leader for a short time after they write, or always for their own data, or have the client send the position or timestamp of its last write and only serve the read from a replica that has applied it.

What are monotonic reads?

A guarantee that a user never sees older data after having seen newer data. It is commonly provided by pinning each user to one replica or by tracking the latest version a client has observed.

What is consistent prefix, with an example?

Readers see writes in an order that respects causality, so a reply is never visible before the message it answers. It is provided by keeping related writes in one partition or by causal ordering metadata.

Where would you use eventual consistency in a social app?

Like counts, view counts, follower counts, feeds and search indexes, where a briefly stale value harms nobody and availability and low latency matter more.

How do consistency models relate to CAP?

Stronger models need replicas to coordinate, so during a partition they must sacrifice availability, and in normal operation they add latency (PACELC). Weaker models stay available and fast but expose stale or reordered reads.