A team's Next.js App Router codebase ends every Server Action with revalidatePath('/', 'layout'). Reads to the upstream API have grown far faster than traffic. Explain what that call invalidates, why it produces this symptom, and how you would narrow it without reintroducing stale data.

## What that call means `revalidatePath` takes an optional second argument, `'page'` or `'layout'`. `'page'` invalidates the specific route; `'layout'` invalidates that layout segment *and every route nested under it*. Passing `'/'` with `'layout'` therefore names the root layout — which every route in the app is nested under. It is documented as the way to invalidate everything, and that is exactly what it does. Run it at the end of every action and you have coupled the entire cache's lifetime to the frequency of unrelated writes. ## Why upstream reads outgrow traffic Caching converts N requests into one upstream read. Invalidating everything on every mutation breaks that ratio in a specific, measurable way: - Every cached `fetch` result behind every route is stale, so the next render of each route refetches — including data no user changed. - Statically rendered routes lose their cached render and are produced again. - The client Router Cache is expired too, so a user's next `<Link>` navigation goes to the server instead of being instant. In a busy app, mutations are frequent enough that few cache entries live long enough to be reused, so read volume converges on "once per navigation" — the pattern the cache existed to avoid. The tell in the metrics is exactly the one described: upstream reads correlate with write volume rather than with page views, and p95 navigation time is worst immediately after any user interaction. ## Narrowing without regressing The goal is invalidation proportional to the change. **1. Establish what each write actually affects.** For each action, list the entities it mutates. This is the step teams skip; the sledgehammer is usually a symptom of not knowing the read dependencies. **2. Tag reads by entity, at the read site.** ```ts export async function getPost(id: string) { const res = await fetch(`https://api.example.com/posts/${id}`, { next: { tags: ['posts', `post-${id}`] }, }) return res.json() } ``` Collection tag plus per-entity tag is the workhorse pattern: editing one post invalidates that post everywhere it is rendered, and the collection tag only when membership or ordering changed. **3. Invalidate only those tags in the action.** ```ts 'use server' import { revalidateTag } from 'next/cache' export async function updatePost(id: string, data: FormData) { await save(id, data) revalidateTag(`post-${id}`) } ``` **4. Keep paths for the route-shaped remainder.** Some routes read outside the tagged layer — a direct database query, a generated feed, a sitemap. `revalidatePath('/sitemap.xml')` or `revalidatePath('/posts/[slug]', 'page')` covers those precisely. The dynamic-pattern form is the right tool when a change genuinely affects all instances of a parameterised route. **5. Migrate action by action, watching the numbers.** Replace the blanket call in one action, confirm upstream reads drop and nothing goes stale, then move on. A big-bang removal across dozens of actions is how the stale-data bugs that motivated the sledgehammer come back. ## The judgment part Over-invalidation and stale data are two ends of one dial, and the honest answer is that they are not equally bad everywhere. A published-price surface may deserve heavy-handed invalidation; a comment count does not. Decide per surface, and prefer a per-entity tag over a coarse one wherever the entity is identifiable. Also keep the invalidation next to the write. When invalidation lives in UI code or in a shared wrapper, nobody can tell what a given mutation affects, and the next person under time pressure reaches for the root-layout call again — which is how these codebases end up here in the first place. ## What you should be able to defend Why `'layout'` at `'/'` is app-wide rather than "just the shell"; why the symptom is read volume tracking writes; a concrete narrowing plan with tags; and a rollout that verifies rather than assumes. Saying only "use tags instead" without explaining the blast-radius mechanism is the weak version of this answer.