Your User Paid. Your Screen Says Unpaid. That Is a Stale Data Bug, Not a Glitch

Your user just paid. The screen still says unpaid. They pay again. Now support has two charges, one angry customer, and a bug report that says "payment broken" when the payment worked fine.

That is stale data. Not a glitch, not a flaky API, not a user error. Your UI showed yesterday's truth with today's confidence, and the user believed the screen over their bank.

Watch the 40-second version here: https://www.youtube.com/shorts/QG8xyG5YHCU

Freshness is a decision, not a hope

Most teams treat data freshness like weather. Something to complain about, nothing to control. Then they cache aggressively, refetch never, and act surprised when the UI lies.

Freshness is a policy you choose per piece of data, and you choose it before the incident, not during it. Three questions decide it. How bad is it if this is wrong? How fast does it change? How expensive is it to recheck? A user avatar can be an hour old and nobody cares. A payment status cannot be five seconds old.

The three moves that actually fix it

First, stamp everything. Every piece of server data your UI shows should carry a version, a timestamp, or an ETag. If you cannot say how old the data on screen is, you cannot reason about it. A "last updated" line is not decoration. It is the difference between "the system is wrong" and "the system is catching up."

Second, revalidate on the moments that matter. On focus, on reconnect, after any mutation. The user who comes back to a tab after lunch should not be staring at lunch's data. These are cheap revalidations, and they catch exactly the cases that generate support tickets.

Third, set a freshness budget and enforce it. Say it out loud: payment status, 0 seconds stale. Order status, 30 seconds. Catalog data, 5 minutes. Then build the rule into code, not into a wiki page nobody reads. A budget nobody enforces is a wish.

Here is the part people miss. Stale data is a trust problem, not just a caching problem. Every confident lie costs trust, and no performance tuning buys that back.

The checklist

• Every server-backed screen names its freshness budget: what data, how old it may be, what triggers a recheck.
• Mutations invalidate or optimistically update the affected data immediately. No "refresh to see your change."
• Reconnect and refocus trigger revalidation for anything the user can act on.
• Anything money, identity, or permission related is never served from a stale cache without a fresh check.

In an interview, do not start with cache headers. Start with the user who paid twice. Then walk through stamp, revalidate, budget. The interviewer is not scoring your knowledge of HTTP caching. They are scoring whether you think about the person staring at the wrong screen.

I turned the full 60-question drill set into The Frontend System Design Interview Playbook ($19): https://bittalk.gumroad.com/l/frontend-interview-playbook

I broke this down in 40 seconds here: https://www.youtube.com/shorts/QG8xyG5YHCU