Safety- or time-critical data must not default to a stale cache

What it is

Some data becomes a wrong act or a wrong judgement one beat late: balances and limits, permission and session, stock and tickets, OTPs and lockouts, medical or safety alerts. Default presentation for that data must be confirmed as of now. It must not paint cache first and hope a mark and a silent refresh will patch it. Acceleration here buys a possibly irreversible false world. Time-critical is not “nicer if fresher”. It is “the old frame is not allowed as the default”.

Why it happens

Cache acceleration assumes the cost of treating an old replica as now is acceptable. Safety and time rewrite that cost: pay against an old balance, walk in on old permission, order against old stock, take no action on an alert that has already expired. A mark changes whether people know it is old. People who do not know will act wrong; people who know may still tap the old world before latest arrives — because the default already put a tappable world in front of them. If silent refresh delivers the truth after the tap, the truth becomes a rollback, and rollback on money and permission is more expensive than waiting one round at the start.

So on these objects’ critical path, a network round trip (or an equivalent live channel) must sit before the first frame, or before tappable. The allowed degradation is an explicit block: “confirming balance”, not a tappable old balance. Shell and decoration may still cache; what is protected are the fields that change a decision or an authorisation.

Where it stops holding

“Critical” is per field, not per page. Product copy may be stale; price and available quantity may not. An avatar on settings may be stale; login state may not. When people have explicitly gone offline, critical data should become “cannot confirm”, not “show last time and let them treat it as now” — last time may be read-only inspection, it must not carry the action. A very short confirmation window (just confirmed hundreds of milliseconds ago) may count as now; that is a window, not a long stale default. Where regulation requires showing the latest rate, perceived performance is not an exemption.

Applying it

• Mark fields as fresh-required: balance, permission, stock, tickets, alerts. Those fields do not paint stale by default.
• Their controls are unavailable until confirmed. “Confirming” may show; a tappable old value may not.
• Non-critical blocks on the same page may still cache, so one critical field does not throw away every acceleration.
• How to check: change the balance on the server, leave the old balance in local cache, open pay. If the old balance appears first and is tappable, stale was the default. Correct is not payable until confirmed, then the new balance. Then try offline: cannot confirm, not complete payment on the old balance.

Related

• Same group: I2.12.1 Cache speeds presentation but risks disagreeing with the server · 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
• Nearby: I4.07 Freshness levels and consistency expectations · I3.02 Optimistic updates · I2.08 Load failure
• Search terms: fresh-required · no stale default · safety-critical cache