Your team is upgrading a large Next.js App Router app to a version where server caching is opt-in rather than applied by default, and routes that used to be static now do work on every request. How do you decide what gets `'use cache'`, and how do you roll that out?

## Reframe the problem The upgrade did not remove a feature; it removed a default. Work that was previously cached because the framework decided to is now uncached because nobody asked for it. The instinct — get the graphs back to where they were, quickly — points straight at the worst available action: adding `'use cache'` broadly and finding out later which entries were user-specific. A performance regression is visible, embarrassing and reversible. A cache serving one customer's data to another is none of those things. So the first move is to slow the loop down enough to classify, and the second is to sequence the work so the highest-value, lowest-risk cases land first. ## Measure before you cache Not every route regressed, and not every regression matters. Worth establishing before touching code: - Which routes changed rendering behaviour, and what their traffic share is. - Where server time actually goes on those routes — one slow upstream call usually dominates, and caching that one function recovers most of the loss. - What was previously being cached that nobody had noticed. Migrations of this kind routinely surface a query that was quietly served from cache for a year and is far more expensive than the team believed. This alone tends to shrink the work from "the whole app" to a handful of loaders. ## Classify the data, not the routes The decision is per dataset: **Shared and user-independent.** Product catalogues, published articles, navigation, pricing, reference data. Cache these first and generously — high hit rate, no confidentiality question, and the freshness requirement is usually measured in minutes. Give each an explicit `cacheLife` profile and a `cacheTag` so publication and edit paths can invalidate immediately rather than waiting on a clock. **Tenant-scoped.** A team's projects, an organization's settings. Cacheable, with the tenant id passed in as an argument so it forms part of the key, and only after authorization has happened in uncached, request-scoped code. The entry now holds one tenant's data, so invalidation on membership and permission changes must exist before this ships. **Per user.** Notification counts, personal drafts, anything derived from the individual. Leave uncached by default. Key cardinality equals the user count so the hit rate is poor, and each entry is personal data with logout, permission-change and deletion semantics attached. If a specific case genuinely needs it, it should be an argued exception with an invalidation plan, not a default. ## Sequence the rollout Route by route, highest traffic first, each change small enough to attribute. For each one: add the directive with an explicit profile and tag, wire the invalidation from the write path, ship, and watch two signals before moving on — the cache hit rate, and something that would reveal staleness (a support-ticket category, a content-team check, a synthetic that publishes and re-reads). A cache with no staleness signal is a cache nobody will trust enough to leave in place. A reasonable stopping rule: once the regression is closed on the routes that carry most traffic, stop. The remaining long tail is usually not worth the invalidation surface it adds. ## Institutionalise the policy The durable output is not the directives; it is the policy. Named `cacheLife` profiles declared once and applied by data class turn freshness into something a reviewer can read — `'catalog'`, `'article'`, `'pricing'` — instead of a number someone guessed at a call site. A short review rule ("nothing request-derived may enter a cached function; tenant-scoped entries need an invalidation path") catches the dangerous cases in code review rather than in production. ## What to say about the tradeoff It is worth being straight that opt-in caching is more work than opt-out, and that the framework made that trade deliberately. Opt-out caching gave good default numbers and an invisible policy — the reason teams shipped stale-data bugs they could not explain was that nothing in the source said what was cached. Opt-in caching costs a migration and ongoing diligence, and buys a codebase where the caching behaviour is legible at the call site. The migration is expensive precisely once; the legibility is permanent. That framing is usually what the question is really testing.