Different features need different freshness; not everything must be latest

What it is

A chat message a second late is read as a dropped connection. A profile photo an hour late is almost never a fault. Different features need different freshness: each region of the interface has its own budget for “still fresh enough”. The whole product does not have to be pushed onto one “always latest” line. How fast the channel can go, and whether this content needs that speed, are two ledgers.

Why it happens

Features bind to different decisions. An in-flight conversation, a collaborative caret, a payment balance — the decision uses this second’s value; one beat old, and the wrong thing is done. A settings page, help, yesterday’s report — the decision uses a structurally stable edition; second-level refresh buys no new decision, only request and redraw cost. Aligning every feature to the strictest band is spending the most expensive channel on the surfaces that care least about freshness.

“Feature” has to land on an independently refreshable region, not a product name. On one screen, the message stream, the headcount, the sidebar ad, the footer copyright can differ by orders of magnitude in budget. A unified chase after latest usually comes from a capability-side reason — “we shipped push” — not from what this region would get wrong.

Where it stops holding

A compliance snapshot, an end-of-day close, an exam paper: latest would break a product constraint of “frozen at this instant”. The freshness budget is an upper bound of no further updates, not “newer is better”. Incident state and risk-control switches can temporarily raise the budget to the strictest; ordinary banding must not block that raise. When several devices write the same document, each end thinks it is “in flight”; banding that treats one end as static material will have that end read a conflict as a freshness problem, when it is a write conflict.

Applying it

• Write a budget for each independently refreshable region: instant, seconds, minutes, per session, per day. Write it against “what goes wrong if this is old”, not against the stack.
• Attach only the strictest regions to the expensive channel. The rest refresh more sparsely, or once on enter.
• Different bands may coexist on one screen. Do not push the whole page to push for a sidebar to be latest.
• How to check: drop refresh on non-critical regions to once-on-enter; keep the critical path (conversation, balance) instant. Stale on the critical path should be a fault; an hour-old profile page should not enter the incident list. Wiring the whole site to instant, as a counterexample, should show request volume on non-critical regions with no decision gain.

Related

• Same group: I4.07.2 Freshness expectations follow content type, not what the system can do · I4.07.3 Label freshness so people do not misread how current the data is · I4.07.4 Strong consistency and high freshness usually trade off; products must pick
• Nearby: I4.03 Polling versus push · I2.12 Cache and stale content
• Search terms: per-feature freshness · freshness budget · not everything realtime