User A updates their profile photo. Three seconds later, User A reloads the page and sees their old photo. Ten seconds later, User B sees the old photo. Which consistency guarantee does this scenario violate, and which does it not?
AIt violates linearizability but not read-after-write consistency, because linearizability covers all clients
BIt violates eventual consistency, because the system has not yet converged after a sufficient delay
CIt violates read-after-write consistency (User A saw stale data on their own subsequent read) but not necessarily linearizability (which requires global ordering of all operations)
DIt violates monotonic read consistency because User B saw a value different from what User A saw
Read-after-write consistency is scoped to the writer's own session: after you write, your own reads must see the write. User A's experience (writer not seeing their own update) is a direct RaW violation. User B seeing the old photo is expected under eventual consistency — other clients may see stale data until replication catches up. Linearizability would require all clients to see the write immediately, but RaW makes no such promise about other clients.
Question 2 Multiple Choice
Why is read-after-write consistency dramatically cheaper to implement than linearizability in a replicated database?
ARaW uses fewer replicas for fault tolerance, reducing the infrastructure cost
BRaW does not require any coordination between nodes, since each client handles its own reads independently
CRaW only requires coordination within a single client's session — routing that client's reads to an up-to-date node — while linearizability requires global ordering of every operation across all clients
DRaW applies only to read operations, so writes proceed without any consistency overhead
Linearizability requires every operation to take effect at a single globally-agreed moment, which demands coordination across all replicas on every read and write. This is expensive in latency and reduces availability. RaW consistency only requires that one client's reads see that client's own writes — a much narrower coordination scope. A simple implementation (route the client to the primary for a short window, or require replicas to have a minimum version before serving reads) achieves this without cross-client synchronization.
Question 3 True / False
Read-after-write consistency guarantees that after you write a value, most clients reading the system will immediately see your write.
TTrue
FFalse
Answer: False
RaW consistency — also called session consistency — only guarantees that *you*, the writer, will see your own subsequent reads reflect the write. Other clients may still see stale data until replication propagates the update. This is what distinguishes RaW from linearizability (which requires all clients to see the write as if it happened atomically at a single point) and even from causal consistency (which propagates visibility to clients that have seen a causally related event).
Question 4 True / False
One correct implementation of read-after-write consistency involves the client tracking the version of its last write and requiring any replica serving its reads to have at least that version before responding.
TTrue
FFalse
Answer: True
Version-based routing is a clean implementation of RaW. The client receives a version token (logical timestamp, LSN, or similar) after each write. On subsequent reads, the client passes this token, and the system either routes the request to a replica that has applied at least that version, or makes the replica wait until it catches up. This ensures the writer always sees their own writes without pinning the client permanently to the primary, allowing reads to return to replicas once replication has propagated.
Question 5 Short Answer
Explain why read-after-write consistency captures the most important user expectation in replicated systems while being much cheaper than strong consistency (linearizability).
Think about your answer, then reveal below.
Model answer: The most jarring anomaly in replicated systems is when a user's own action appears not to have worked — they update something and then see the old value, suggesting their write was lost. RaW eliminates this specific class of surprise by guaranteeing the writer sees their own writes. Other anomalies (another user seeing stale data, or observing writes in a different order) are less immediately confusing and acceptable under eventual consistency. Linearizability eliminates all anomalies but requires global coordination on every operation; RaW eliminates only the most user-visible one with much cheaper session-scoped coordination.
This tradeoff explains why RaW is the default or common option in systems like DynamoDB and MongoDB. Users reliably distinguish 'my change isn't showing up' (RaW violation) from 'someone else's change isn't showing up yet' (acceptable eventual consistency lag). By targeting the former specifically, RaW provides a practical consistency level that matches user mental models without paying the full price of global strong consistency.