Consistency models from strong to eventual

Distributed systems Senior Python 3.13+ PostgreSQL 17+ Reviewed By Best Latest Apps

Pick the fix

Users post a comment, the page reloads from a read replica, and the comment is missing for a second. Cheapest fix?

Options
Hint 1 of 1

Which guarantee does the user actually need?

Choose an answer, then open Show answer below to check it.

Show answer

Answer: A Read that user's data from the primary for a few seconds after they write

Correct. Gives read-your-writes where it matters without making every read strongly consistent.

Read-your-writes is the guarantee users notice: they expect to see their own comment. Sending only that user's reads to the primary for a short while fixes it without slowing every write.

Why not the others?
  • B Make all replicas synchronous. Fixes it at a large latency and availability cost for every write.
  • C Add a CDN. A cache makes staleness worse.
  • D Switch to eventual consistency. That's what you already have.

30-second answer

Linearizable: the system behaves like one copy; once a write completes, every later read sees it. Causal: operations that depend on each other are seen in that order by everyone, while unrelated ones may appear in different orders. Read-your-writes: a client always sees its own updates. Eventual: if writes stop, replicas converge, with no promise about when or what you read meanwhile.

Practise saying it · 40 s. No recording, just a timer

Compare consistency models.

Say your answer out loud, then check which of these points you covered:

  • Linearizable: one copy
  • Causal: dependencies ordered
  • Read-your-writes: session
  • Eventual: converge later
  • Conflict resolution

Deep dive

Session guarantees (read-your-writes, monotonic reads, monotonic writes) are cheap and fix most user-visible weirdness.

Monotonic reads: a user never sees data go back in time, for example by sticking a session to one replica.

Linearizability needs coordination on every write (and often reads), which costs latency across regions.

Eventual consistency needs a conflict rule: last-writer-wins drops data silently; CRDTs merge.

Common mistakes

  • Calling any replicated system 'eventually consistent' without saying how conflicts resolve.
  • Promising linearizability across regions without accounting for the round-trip cost.
  • Ignoring that a user posting a comment and not seeing it is a read-your-writes bug, not a cache bug.

Senior take & follow-ups

Define each from the client's view, and point out session guarantees as the practical middle ground.

Follow-up questions

Think of your answer first, then open the hint.

  1. How do you get read-your-writes with async replicas?

    Show hint

    Read from the leader for a short time after a write, or wait until the replica has the write's log position.

  2. What's a CRDT?

    Show hint

    A data type whose concurrent updates merge deterministically, like a grow-only counter.

Related questions

Suggest a fix if something here is wrong or out of date.