Design for the Delay Between Writing and Reading
Systems & Architecture · consistency, real-time, status
Updated 2026-08-04
- Assume a write does not appear everywhere at the same moment. Most products send reads to copies of the database that trail the original by anywhere from milliseconds to seconds, a gap called replication lag, so a user can save something and then not see it.
- Never let a user's own change disappear from their own screen. After a successful save, render the value the interface already holds rather than re-reading it, so a lagging copy cannot contradict what the person just did.
- Treat the reload after a save as the dangerous moment. A user who saves, refreshes, and sees the old value concludes the save failed, and their second attempt creates the duplicate.
- Name the places where the delay is visible and design each one:
- A list that will not show the item that was just created.
- A counter that has not moved yet.
- A second device or tab showing the previous value.
- A shared view where a teammate sees the change later than the author.
- Prefer showing the change immediately and reconciling quietly over showing a spinner while the copies catch up. The interface stays truthful as long as a failed reconciliation visibly reverts.
- Say Updating rather than Saved when the write is confirmed but not yet everywhere. It costs one word and prevents a support ticket.
- Give anything time sensitive a way to force a fresh read. An account balance, a stock count, and a permission change all deserve a path that skips the lagging copy.
- Test with the delay switched on. A local database answers instantly and hides every one of these states, which is why they reach production undesigned.
The gap between saving and seeing is normal engineering, and it becomes a bug only when the interface pretends the gap does not exist.
Related guides
UX Handbook