Stale While Revalidate
Serving cached data immediately while fetching a fresh copy in the background, which makes an interface feel instant at the cost of a brief inconsistency.
The alternative arrangements are worse. Fetching fresh on every view shows a spinner every time, including when returning to a page visited seconds ago. Serving the cache without revalidating shows data that may be hours old with no path to correction.
Stale-while-revalidate does both: render the cached value immediately, request an update in the background, and re-render if it differs. Perceived latency is zero for anything previously loaded, and the data converges.
The trade is a window where the display is knowingly out of date, which is acceptable for a product listing and not for an account balance or a stock availability shown at the point of purchase. That judgement is per resource, and the cache configuration should express it rather than applying one policy everywhere.
The companion problem is invalidation after a mutation. Having submitted a change, the client's cached copies of everything affected are wrong, and the options are to invalidate by key — precise, requires knowing the relationships — or to invalidate broadly and refetch, which is simpler and noisier. Getting this wrong is what produces the familiar bug where an item is deleted and reappears on navigation.