The Next.js App Router is usually described as having four caching layers. Name them, and for each say where it physically lives and how long an entry lasts.

## Why there are four Next.js does not have "a cache" you clear in one place. The App Router caches at four separate points along the path from an upstream API to a pixel on screen, and each point has its own storage, its own key, and its own expiry rule. Interviewers ask this because someone who has only used the framework casually will describe it as a single opaque cache and then be unable to explain why a hard reload fixes their bug but clicking a link does not. | Layer | Where it lives | What it stores | Lifetime | |---|---|---|---| | Request Memoization | Server, in memory | Return value of a `fetch` call | One render pass of one request | | Data Cache | Server, durable storage | Response bodies from `fetch` | Persistent; survives deployments until revalidated | | Full Route Cache | Server, build output | Rendered output of a static route | Persistent; rebuilt by a new deployment | | Router Cache | The user's browser, in memory | Payload of visited route segments | The browsing session; cleared by a full reload | ## 1. Request Memoization This one is not really a Next.js feature — React extends `fetch` so that two calls with the same URL and the same options inside a single render are collapsed into one network request. It exists so you can call a `getUser()` helper from a layout, a page, and a leaf component without hand-threading the result down through props. Its scope is exactly one render of one request. It is not shared between users, not shared between two requests from the same user, and nothing about it persists. It is also independent of the Data Cache: a request you have explicitly opted out of caching is still deduplicated inside a single render, because the two mechanisms answer different questions ("did I already ask this during this render?" versus "do I have a stored copy from earlier?"). Memoization applies to `GET` requests made during the React render; work outside the component tree, such as a route handler, is not part of that render pass. ## 2. The Data Cache The Data Cache is a server-side store of actual response bodies, keyed by the request that produced them. It sits between your code and the upstream API, so a cached entry can serve every user and every request that asks for the same thing. It is the layer with the longest memory: it is designed to persist across deployments, so shipping a new build does not by itself hand you fresh data. That persistence is the property most candidates get wrong, and it is also the one that bites teams in production — you fix how you shape an upstream response, deploy, and the old shape keeps coming back out of the cache. ## 3. The Full Route Cache Where the Data Cache stores inputs, the Full Route Cache stores outputs: the rendered result of a route that Next.js was able to render statically, produced at build time (or when the route is regenerated). Serving a request then means handing back stored output instead of rendering anything. Only statically rendered routes have entries here; a route that must be rendered per request has nothing to store. Because the entries are a product of the build, a new deployment replaces them. The two server layers are stacked, not parallel: invalidating the data a route depends on causes that route to be rendered again, which replaces its stored output. ## 4. The Router Cache The Router Cache is the only layer that is not on your servers. As the user navigates, the browser keeps the payload for segments it has already visited or prefetched in JavaScript memory, so a soft navigation back to a page you just left can be rendered from memory. It is per browser, per session — nobody else can see it, and it does not follow the user to another device. It is cleared by anything that discards that JavaScript memory, most obviously a full page reload. How long a segment stays reusable before Next.js goes back to the server is version-sensitive: through Next.js 14 a dynamically rendered page was reused for about 30 seconds, and Next.js 15 changed the default reuse window for page segments to zero so navigations go back to the server, with `experimental.staleTimes` in `next.config` available to tune it. Layout segments continue to be reused across navigations. ## Reading a request down the stack A navigation checks the browser's Router Cache first. If it has to go to the server, a statically rendered route can be answered from the Full Route Cache without rendering. If rendering does happen, each `fetch` is deduplicated for that render by memoization and may be answered from the Data Cache instead of going upstream. Knowing that order is what lets you name the guilty layer from a symptom rather than guessing.