The four Next.js caches — and why your data doesn't update

The four layers, from innermost to closest-to-user

By the end of this section you’ll be able to name which cache is responsible for each stale-data symptom you encounter and pick the right invalidation lever instead of reaching for a blanket no-store.

Request Memoization is React, not infrastructure: identical fetch calls (same URL, same options, GET) made during a single server render pass execute once; the rest get the memoized result. Lifetime: one request — the memo table dies when the render finishes. This is why a layout and a page can both call getUser() without a double round-trip, and why you don’t thread props from layout to page. It only deduplicates within one render; it never serves anything to a second request. For non-fetch work (a direct DB query), React.cache() gives the same per-request memoization.

The Data Cache is the server-side store of fetch responses, keyed by URL plus options. Its defining — and most surprising — property: it is persistent across incoming requests and across deployments. Shipping new code does not clear it; the Friday price bug lives here. You control it per-fetch: next: { revalidate: 3600 } for time-based expiry, next: { tags: ['products'] } for on-demand purging with revalidateTag, cache: 'no-store' to bypass entirely. In Next 14 and earlier, fetch responses were cached here by default (force-cache); in Next 15 the default flipped to uncached — more on that below.

The Full Route Cache is the rendered output of statically rendered routes — the RSC payload plus HTML — produced at build time or in the background after a revalidation. It’s what makes a static route answer in single-digit milliseconds without running your components. Scope: server; lifetime: until revalidation, and unlike the Data Cache it is cleared on every deploy. Routes that use dynamic APIs — cookies(), headers(), reading searchParams in a page, or dynamic = 'force-dynamic' — opt out entirely and render per request.

The Router Cache lives in the browser’s memory: it stores the RSC payload of visited route segments for the session, so back/forward navigation is instant and prefetched links navigate without a server round trip. It is the only client-side layer, and the only one your server cannot directly flush — it empties on a hard reload, on router.refresh(), or when a server action calls revalidatePath/revalidateTag or sets a cookie.

// One fetch, three cache decisions:
const res = await fetch('https://cms.example.com/api/products/42', {
  next: {
    revalidate: 3600,        // Data Cache: stale after 1h, refreshed in background
    tags: ['products', 'product-42'], // Data Cache: purgeable on demand
  },
});

// In the server action that edits the product:
import { revalidateTag } from 'next/cache';

export async function updateProduct(formData: FormData) {
  'use server';
  await db.product.update(/* ... */);
  revalidateTag('product-42'); // purges Data Cache entries → Full Route Cache
                               // regenerates → client Router Cache invalidated
}

Tradeoff: each layer trades freshness for a different cost. Memoization is free correctness. The Data Cache saves origin load but can serve data that no longer exists, across deploys. The Full Route Cache gives CDN-grade latency but only to routes that renounce per-request data. The Router Cache makes navigation feel native but means the server can be fixed while a user’s tab still shows the bug.

Invalidation: revalidate, tags, and opting out

Time-based revalidation (revalidate: 3600, or export const revalidate = 3600 at the segment level) works like stale-while-revalidate: the first request after expiry still gets the stale entry, the refetch happens in the background, and the next request sees fresh data. That “one more stale hit” surprises people who expect a hard TTL.

On-demand invalidation is the precise tool: revalidateTag('products') purges every Data Cache entry tagged with it and invalidates the Full Route Cache of routes built from it; revalidatePath('/products') does the same by route. Called inside a server action, they also invalidate the client’s Router Cache for affected paths, so the user who made the mutation sees the result immediately. Called from a route handler (say, a CMS webhook — the right fix for the Friday bug), they fix the server caches but cannot reach into browsers; open tabs catch up on their next hard navigation or refresh.

Opting out is per-layer: cache: 'no-store' skips the Data Cache for one fetch; export const dynamic = 'force-dynamic' makes the whole route render per request (skipping the Full Route Cache); using cookies() or headers() does the same implicitly. Note the asymmetry: an uncached fetch inside an otherwise static route makes the route dynamic — but the route being dynamic does not stop its fetches from using the Data Cache. Route caching and data caching are independent axes.

Diagnosing “my data doesn’t update”, layer by layer

This is the most-filed Next.js bug in production, and it yields to an ordered walk — server first, client last.

Step 1 — is the route static? Check the build output: a circle marker means static, an ƒ means dynamic. If it’s static and your data must be per-request, the Full Route Cache is serving build-time HTML and no fetch option will save you — the route needs dynamic = 'force-dynamic' or a dynamic API. If it should be static but periodically fresh, set revalidate.

Step 2 — is the fetch cached? On Next 14, a bare fetch defaults to force-cache: your entry may be months old and deploy-proof. Decide its real freshness contract: a revalidate window, tags plus webhook-driven revalidateTag, or no-store if it’s genuinely per-request.

Step 3 — does the mutation invalidate? A server action that writes to the database but never calls revalidatePath/revalidateTag leaves every cache intact — the write succeeded, the caches just weren’t told. This is the single most common omission.

Step 4 — is it only stale in one browser tab? Server responds fresh via curl, but the user sees old data on back-navigation: that’s the Router Cache. If the staleness follows a mutation, the fix belongs in step 3 (actions invalidate the Router Cache too); for “data changed elsewhere” freshness, router.refresh() or accepting session-scoped staleness are the options.

Together these four steps mean you always have a culprit before you touch code: if it’s stale after deploy, it’s the Data Cache; if only one tab, it’s the Router Cache; if the route’s build output shows a circle, it’s the Full Route Cache. Without step 1, you can waste an hour adding no-store to a fetch inside a statically rendered route where no fetch ever runs per request.

The discipline is to name the layer before reaching for a fix. Sprinkling no-store everywhere “works” by collapsing all four layers — and triples your origin load, which is how the Friday hotfix took down p95.

Next 15 flipped the defaults — version your advice

Everything above describes mechanics common to both majors, but the defaults changed materially in Next 15, and half the advice on the internet silently assumes the wrong one. In Next 15: fetch is no longer cached by default (no-store semantics unless you opt in with cache: 'force-cache' or a revalidate option), GET route handlers are no longer cached by default, and the Router Cache no longer reuses page segments by default (staleTime of 0 for pages — a fresh navigation refetches the page, while back/forward restoration and layouts still come from the cache; tunable via the staleTimes config). The Full Route Cache and static rendering remain defaults for routes without dynamic APIs.

Practically: on a Next 15 codebase, the Friday bug as told mostly can’t happen with a bare fetch — but it returns the moment someone adds force-cache for performance and forgets the invalidation half of the deal. And teams upgrading from 14 see the mirror-image incident: origin traffic jumps after the upgrade because every formerly-default-cached fetch now hits the source per request. Before debugging any caching behavior, run next --version — the same code has different semantics across that boundary.