Design for Content Cached Outside Your Control

Systems & Architecture · caching, performance, status

Updated 2026-08-04

Assume every response is stored somewhere between your database and the user's eye. Browser caches, service workers, the CDN at the edge, and the app's own memory all hold copies that can outlive the change.
Expect the classic failure: the data updates, the cache does not, and the user refreshes into their old profile. The database is correct and the product looks broken, which is the worst combination to debug from a screenshot.
Show when the screen was last refreshed for anything that changes on its own. A timestamp turns a stale screen into an informative one.
Give the user a refresh that genuinely bypasses the cache, and make it visibly do something. A refresh button that returns the same stale value in twenty milliseconds reads as broken.
Decide the freshness of each surface deliberately:

Marketing and help content can be minutes or hours old.
Lists and dashboards should be seconds old, with the age shown.
Balances, permissions, and stock counts should never be served from a shared cache.

Never cache a personalized response in a shared layer. One user's name, cart, or account leaking into another user's page is the most expensive caching bug there is.
Version the interface's own assets so a deploy cannot leave people running old code against new data. Stale scripts fail silently and look like content bugs.
Give support a way to see what the user sees. Half of all "it still shows the old price" reports are cache reports, and they are unanswerable without that.

A cache never tells you it is wrong, so the interface has to carry the age of what it is showing.