The idea
A common database layout sends writes to one copy and serves reads from several others. Those read copies may receive updates asynchronously. That keeps a slow or unavailable follower from delaying every write, but it creates a window in which two correct copies hold different versions.
The useful design question is not simply “Is the system consistent?” It is “What sequence of observations must this user be able to trust?” A person usually expects to see a change they just made. They also expect repeated refreshes not to move backward to an older version. These are concrete product promises, and the application can protect them selectively.
Make it concrete
Priya changes her profile photo, then immediately opens her profile. If that read goes to a lagging follower, the old photo reappears and the save looks broken. The app could temporarily route Priya’s own profile reads to the leader, attach a version to the write and wait until a replica has caught up, or show the accepted update optimistically. Other visitors can continue using replicas because a few seconds of staleness matters less to them.
Choose guarantees by journey
For each important flow, identify who wrote the data, who reads it next, and what harm stale or out-of-order results would cause. Account settings may need read-your-writes behavior. A news feed may tolerate delay. A sequence of status updates may need monotonic reads so it never appears to reverse. Stronger coordination has a cost, so spend it where the user promise requires it.
Try it
Pick one write-then-read journey in a system you know. What would a lagging copy show? Decide whether to route, wait, pin the session to one replica, or let the interface bridge the delay—and explain why.