The interview question. A user changes their display name on a phone. The update succeeds, but opening their account on a laptop immediately afterward shows the previous name. Reads are routed to nearby database replicas, and writes go to a primary. Design a practical read-your-writes guarantee. What changes if the user switches devices, the client loses its session token, or the required replica is slow?
For this exercise, the accepted write remains in the authoritative history, and replicas eventually catch up. There is no regional data loss. We are designing a user-visible session guarantee, not the lower-level WAL application mechanism covered in the previous lesson.
Think first
A user changes a profile field on a phone and immediately opens the account on a laptop. The closest replica has applied version 83 but the accepted write is version 84. Design a cross-device read-your-writes contract. Explain where the minimum version lives and how you respond if the replica cannot catch up within 150 ms.
Take a few minutes to form an approach, then compare it with the worked explanation.
Reveal the worked explanation
One user, two requests, two copies
The phone writes name = Mira, and the primary commits version 84. The laptop's nearest read replica has only applied version 83. Its GET returns the previous display name. The experience is still wrong.
A common reaction is to shorten the replica lag. That helps typical reads but does not cover lag spikes. “It usually catches up in 100 ms” is a performance observation, not a read-your-writes guarantee.
We need to decide what counts as one user's sequence of operations. A server session stored in one browser tab is too narrow when a phone updates data and a laptop immediately requests it.
The phone writes version 84 while the laptop reaches a replica that has only applied version 83
The design tracks the latest acknowledged version for a user or resource in an authoritative service, or passes a trusted consistency token between operations. A client-only token works nicely within one device, but the laptop will not automatically know the token produced by the phone. That is the first question I would ask in an interview: does this guarantee need to cross devices, or only cover one logical client session?
Decide where the minimum version lives
For single-device continuity, the update response can include a signed or otherwise trustworthy marker identifying the acknowledged write. Later reads include it. The read router chooses a copy known to be at least that fresh.
For cross-device continuity, I would not pretend that copying a token between independent browsers happens by magic. One practical design is to keep an account-level minimum-visible version with the authoritative account state and consult it when serving account reads. That metadata must itself be read consistently. Update it atomically with the account change, or derive the minimum from authoritative state before acknowledging success; an acknowledged write followed by a delayed minimum-version update leaves a cross-device race. Otherwise the solution simply moves the staleness bug to the metadata lookup.
In some systems, the account data's own authoritative version can be read first, after which a follower is allowed to serve the full profile only if it has caught up. But this introduces an extra network operation or a cache that also needs a contract. For many applications, routing recent account edits and subsequent profile reads to the primary for a short period is simpler and cheaper to operate.
A richer product may use session consistency support provided by the database. MongoDB, for example, documents causally consistent sessions with majority read and write concerns, including read-your-writes and monotonic-read guarantees. These are conditions on those sessions and concerns, not an automatic property of arbitrary reads from any replica. MongoDB causal consistency.
Notice that a user-scoped contract may intentionally be stronger than a tab-scoped session guarantee. We should name the scope accurately in the API and product documentation.
Waiting, rerouting, or returning an honest error
Suppose the account read has a 150 ms deadline, but the target replica is 400 ms behind during a storage spike. We cannot simultaneously guarantee a fresh answer from that replica and a response within 150 ms. We must choose another allowed path.
I would let the router try a qualified replica if one is available, with a small bounded wait. Otherwise, for this workload, route the read to the primary if it has enough capacity. If the primary is unavailable or overloaded, return an explicit temporary failure rather than quietly downgrading a promise that the user will see the edit.
A settings page can retain the new value in the local UI while background verification happens. But showing an optimistic value is not proof that another device will read it, and it is not a substitute for server-side enforcement on security-sensitive changes.
That distinction becomes critical for password reset, permission revocation, or changing a payout destination. Such operations may require direct authoritative reads or additional barriers regardless of what the profile-cache policy does. We should not let a display-name example silently define the security contract for every field.
What about a follower that falls behind for minutes?
Measure the age and distribution of replica lag, not just the average. Track the share of reads needing fallback, how long they wait for their required version, and whether the primary is being overwhelmed by those fallbacks. A solution that is correct only by routing almost every read to the primary may not meet the original scaling objective.
A proposed requirement like “99.9 percent of profile reads complete within 150 ms and never return an older version than the user's last acknowledged edit” forces an architectural decision. Under a prolonged replica delay, preserving correctness may consume more primary capacity or reduce availability. That trade belongs in the product contract.
Also distinguish a stale replica from stale caches. If a CDN serves the old profile independent of database routing, perfect read-your-writes handling at the database does not fix the end-to-end result. Every layer that can answer the request must either honor the version bound or be bypassed.
The useful idea is not “always read the primary after writing.” It is carry the minimum state the read must include, decide where that obligation lives, and explain the response when no eligible copy is available.
A following system uses no single primary for the key at all. Two replicas may acknowledge a write and two may answer a read. Does their overlap settle every consistency question?
Go deeper
Further technical depth
Scope of a token. A token may represent one document version, a partition log position, or a causal dependency set. It is not automatically a meaningful scalar across unrelated partitions. With account-level data spread over multiple shards, define whether the guarantee is per field, per record, or across the whole account.
Bounded stickiness. Temporary primary routing can be an effective policy for recent writers, but its duration must be a performance choice rather than a promise that replicas always catch up before the timer expires. If the timer ends and the replica is still behind, either check a version or weaken the stated guarantee explicitly.
Security and privacy. Read-after-write on an authentication or authorization change may need an authoritative validation path at the point of enforcement, not just a fresh settings screen. Derived search indexes, edge caches, and offline mobile copies can each have different consistency contracts.
Alternative client protocols. Some databases expose causal session operations or read-at-least timestamps. Use those supported primitives if their scope matches the application. Avoid inventing a globally comparable number without a protocol that establishes its meaning.
Check your reasoning
Name the guarantee and its scope, including whether two devices share a causal session.
Use trustworthy version tracking or authoritative routing rather than a fixed lag-based timeout alone.
Explain how a cross-device shared minimum differs from a phone-local consistency token.
Show wait, alternate replica, primary fallback, and explicit error options under a deadline.
Discuss end-to-end cache behavior and stricter security-sensitive paths.
Common mistake: Saying the laptop automatically receives a causal token from the phone, or promising freshness simply by routing to a nearby read replica.
Read the answer explanation
Shared account-level minimum visible version or an authoritative read route. — A cross-device promise needs shared evidence or authoritative routing. A token known only to the phone does not reach the laptop.
Apply it elsewhere
A customer changes a team role in one browser. A different device immediately calls an authorization API. What becomes stricter than the display-name example?
Compare your approach
Authorization enforcement may require a server-side revocation or version barrier at the decision point, not simply fresh UI state.
One more constraint
How do you prevent the primary from becoming overloaded by fallback reads when replicas lag?
Quick revision
Read-your-writes means a user's later eligible read must include their earlier acknowledged write. Replica lag makes ordinary nearby reads violate that guarantee. For one device, a trusted write-position token can guide routing. Across devices, the server needs shared account-scoped consistency state, authoritative routing, or another explicit synchronization mechanism. Wait for an eligible replica, reroute to the primary, or return an honest failure before the deadline. Never promise freshness merely because typical lag is small.
