Data Cache vs. Full Route Cache vs. Router Cache

The plain-language idea

Earlier lessons covered fetch() caching, "use cache", ISR, and on-demand revalidation individually. This lesson is the map connecting them: Next.js (without cacheComponents enabled) actually has up to three separate caching layers, each solving a different problem, each cleared a different way, and a bug report like "this isn't updating" can be sitting in any one of them.

• The Data Cache — a persistent, server-side cache of individual fetch() results (or unstable_cache() calls), keyed by URL and options. This is what cache: 'force-cache' and next: { revalidate, tags } control. It survives across requests and across users — one fetch result can serve every visitor.
• The Full Route Cache — a persistent, server-side cache of an entire route's rendered output (the HTML and the React Server Component payload), built at build time or on first request for static routes. This is what export const revalidate = N and ISR operate on. A route can be statically rendered even when it makes cached fetch() calls — the Full Route Cache is caching the result of rendering, one layer above the Data Cache it was built from.
• The Router Cache (client-side) — an in-memory cache living in the browser, holding React Server Component payloads for routes the user has already visited or Next.js has prefetched via <Link>. This is why navigating back to a page you were just on can feel instant with no server round trip at all — and why a server-side revalidation doesn't always show up immediately without a client-side signal to also clear this cache.

See it in a real thing: tracing one "stale data" bug through all three layers

// app/products/[id]/page.tsx
export const revalidate = 3600; // Full Route Cache: refresh at most hourly

async function getProduct(id: string) {
  // Data Cache: force-cache + a tag, independent lifetime from the route's
  const res = await fetch(`https://api.example.com/products/${id}`, {
    cache: "force-cache",
    next: { tags: [`product-${id}`] },
  });
  return res.json();
}

export default async function ProductPage({
  params,
}: {
  params: Promise<{ id: string }>;
}) {
  const { id } = await params;
  const product = await getProduct(id);
  return <ProductView product={product} />;
}

An admin updates this product's price in the CMS. Three different fixes apply to three different symptoms:

• If the underlying data is wrong even on a fresh render, the problem is the Data Cache — call revalidateTag(\product-$`, 'max')` from the mutation so the next fetch gets fresh data.
• If the fetch would return fresh data but the page's HTML is still the old snapshot, the problem is the Full Route Cache — revalidatePath('/products/[id]', 'page') clears the cached render itself.
• If the server is genuinely serving updated HTML but a user who already has the page open in their browser still sees the old price after clicking back to it, the problem is the Router Cache — this is why Next.js automatically invalidates the relevant client-side entries when revalidatePath/revalidateTag run inside a Server Action triggered from that same page, but a webhook-driven update from an external system has no such automatic client-side signal to send.

What people usually miss

Watch out

• "It's not updating" is not one bug — it's three possible bugs with three different fixes. Reflexively reaching for revalidateTag when the actual problem is a stale Router Cache entry in one specific browser tab wastes time diagnosing the wrong layer.
• The Full Route Cache caches rendered output, not raw data. A route can have perfectly fresh underlying data (Data Cache revalidated) while still serving a stale cached render (Full Route Cache not yet revalidated) — they're invalidated independently.
• The Router Cache is client-side and per-browser. Clearing every server-side cache doesn't touch a page that's already sitting in one specific visitor's memory — that's a separate, client-only layer with its own invalidation triggers.
• A route with even one uncached, Request-time data source (cookies(), headers(), uncached searchParams usage) opts the whole route out of the Full Route Cache, falling back to dynamic rendering on every request — at which point only the Data Cache layer is still relevant for that route.
• These three caches predate — and coexist alongside — cacheComponents/"use cache". A codebase can be entirely on the classic model (this lesson), entirely on Cache Components, or migrating between the two; "which caching model is this route even using" is the first question, before picking which cache to blame.

Why this matters in interviews

"A user says a page shows stale data after an admin update, and you've already confirmed the database has the new value — where do you start looking?" tests whether a candidate has an actual mental model of Next.js's layered caching, or just knows individual API names without understanding which layer each one clears — the difference between naming revalidateTag and knowing why it might not be the right tool for this particular symptom.