Session Guarantees & Staleness Bounds

Read-your-writes, monotonic reads, monotonic writes, consistent prefix — practical guarantees users feel without full linearizability.

3/5Overview: 20m

Beyond "eventual"

Products rarely need global linearizability everywhere. They need session guarantees — what this user experiences after their writes.

Common session guarantees

GuaranteeMeaning
Read-your-writesAfter you write, you never read an older value
Monotonic readsIf you read v2, you never later read v1 in the same session
Monotonic writesYour writes are applied in order
Consistent prefixYou never see effect of B without A if A causally preceded B
Writes follow readsIf you read then write, your write incorporates what you read

These can be implemented with sticky routing to one replica, version checks, or client-side state — cheaper than cluster-wide linearizability.

Staleness bounds

Some systems advertise bounded staleness (e.g. read at most 5s behind leader). Know the difference:

  • Eventual — no bound
  • Bounded staleness — explicit SLA on lag
  • Linearizable — zero staleness from client's perspective

Dynamo's client-side model

The Dynamo paper popularized read repair, hinted handoff, and vector clocks for conflict detection. Eventual consistency with application-resolved conflicts — still referenced in senior loops when discussing AP systems.

Interview framing

"If users must see their own posts immediately, we need read-your-writes — route that session to the leader or pass a version token. Global timeline for all users is a separate, stricter requirement."

Further Reading