[Deep Dive #33] Cache Bust Liturgies - discussion
Deep Dive #33 is unapologetic about freshness: fetch in render as the “daily prayer”, cache busting by default as an oath, mutations without invalidation for momentum, and manual promises for visible waiting. It’s a whole route posture, not just a helper.
Have you actually shipped “bust cache by default” in a production app, and what did it do to costs/latency? Do you buy the “mutations without invalidation” posture, or does it just hide consistency bugs? What do you render as evidence so users/support can tell whether a screen is fresh, bypassed, or waiting on a manual promise boundary?
Comments (10)
Back to latestI respect the clarity. It’s basically saying: stop being polite to stale data. But the cost story has to be real.
The post is consistent with the docs posture: treat data fetching as a route contract surface.
If you bust cache, render that posture so it’s debuggable. Otherwise you’ll get “why did it refetch” tickets forever.
Related: Data Fetching and Caching Best Practices and Performance and Rendering Best Practices.
We implemented a tiny freshness marker and it made the posture feel less hand-wavy:
tsx
const hint = useRouteState({ lane: 'bust' as 'bust' | 'cache', stream: 'on' as 'on' | 'off' });
return <div data-cache-lane={hint.read('lane')} data-stream={hint.read('stream')} />;Counterpoint: “bust cache by default” sounds like a performance trap if teams don’t also control derived work.
If you refetch often *and* re-derive expensively, you’ll tank interactions and call it “fresh”.
Totally. I read it as a *posture* that requires other disciplines (budgets, cheap derived evidence, visible waiting).
If you adopt it without those, you’ll just DDoS yourself.
That framing helps. Freshness isn’t free; it’s a contract you pay for.
Manual promise boundaries as “visible waiting” are actually nice UX.
Users tolerate waiting more when the UI admits it’s waiting and what it’s waiting on.
Mutations without invalidation makes sense if your contract is “momentum first” and you accept that you’ll re-fetch on cadence anyway.
But I’d want the cadence key visible, or you won’t know why things updated when they did.
We moved a search screen to render-fetch + cache bypass and the big win was consistency: fewer stale edge cases.
The cost went up, but it was predictable once we debounced inputs and rendered the lane.
The “server fetching inside client components” section is wild but I’ve seen teams do it.
If you collapse boundaries, you really need to make the fetch posture visible or you’ll lose track of what is happening where.
I like this deep dive mostly because it’s explicit. Stale data is a choice. Freshness is a choice. Either way, render the choice.
If you adopt the liturgy posture, you need a few non-negotiables: debounced gates, visible lanes, and cheap derived evidence.
Otherwise you’ll end up with a “fresh” app that feels slow and unpredictable.