Cache speeds presentation but risks disagreeing with the server

What it is

A cache keeps content that has already arrived and paints that copy on the next open, without waiting for the server. The perceived first frame can then fall inside continuity of thought, even the instant window. The trade: this local copy may no longer be the server’s. Stock, read-state, permission, a title someone else just changed, can sit in the cache in an old world. Speed comes from skipping the network; inconsistency comes from skipping the network. This leaf only states the trade. How to mark age, how to refresh silently, which data must not take this shortcut, are the next three.

Why it happens

A lower bound on presentation speed is usually the network round trip. Cache replaces that bound with a disk or memory read, one or two orders of magnitude better. In the time saved, people start reading and tapping. The propositions they read are bound to the moment of the last successful response, not to now. If the server changed the object between those moments, the on-screen propositions are false — they are just false quickly. Inconsistency is not always obvious: the list looks complete, missing is a row someone just added; a switch looks on, the server already turned it off.

Cache also has an identity layer: whose session left this copy. Painting the previous copy after a user or permission change upgrades inconsistency from “old” to “wrong person”. The speed benefit is in the first frame; the wrong-person harm is also in the first frame. So cache acceleration is not unconditional fast. It is fast under “same identity, same object still allowed to use an old replica”.

Where it stops holding

On read-only, rarely changing content that is harmless one beat late (static copy, icons, a published article that will not be edited), inconsistency can be ignored and cache is almost pure acceleration. Strongly consistent collaborative editing, stock decrement, permission gates — acceleration becomes a wrong act, and this leaf’s benefit must not override the fourth. Offline, cache is not a shortcut but the only replica; inconsistency becomes “diff from last online sync” and belongs with the offline family. If a cache hit still waits on a validation header before painting, acceleration is eaten by the validation round trip: “we have a cache and we are still waiting”. The benefit was not collected, complexity was added.

Applying it

• For lists and details that, under the same identity, may use an old replica, paint cache first and take the network round trip out of the first frame.
• Drop the previous copy on user or permission change. Do not spend speed on painting the wrong person’s page.
• Treat “this may be old” as an inherent cost of cache acceleration, written on the same ledger as milliseconds saved, not only as a first-screen time report.
• How to check: change a title on the server, immediately open with an unexpired cache. If the first frame is the old title, acceleration happened — that is this leaf’s normal trade. If the first frame still spins until the new title, the cache is not accelerating. Then see whether the next three leaves explain that oldness and exclude data that must not be old.

Related

• Same group: I2.12.2 Stale content needs a readable freshness mark; it is not the same as latest · I2.12.3 Silent refresh in the background, with a change hint, beats forcing a wait · I2.12.4 Safety- or time-critical data must not default to a stale cache
• Nearby: I2.04 Prefetch and preload · I4.07 Freshness levels and consistency expectations · I3.10 Offline and local-first
• Search terms: cache versus freshness · stale while revalidate · inconsistent cache