In a deployed Next.js App Router app, two different users request the same page. Which of Next.js's caching layers can serve both of them from the same stored copy, and which one is private to a single browser?
answer
- server layers serve strangers
- browser layer serves one session
- keyed by request, not by visitor
- one layer serves nobody twice
- personal content must stay unshared
basics
~20 sThe two server-side layers — cached fetch responses and stored route output — are shared, so both users can be served the same copy. The browser's Router Cache is private to one session, and per-render memoization is scoped to a single render so nobody else ever sees it.
solid answer
~50 sThe server layers are shared and the client layer is not. Cached `fetch` responses and stored rendered route output both live on your server and are keyed by the request, not by the visitor, so two users asking for the same thing can be served the same stored copy. Per-render memoization also lives on the server, but its scope is one render of one request, so it is never reused by anyone else. The **Router Cache** is the private one: it holds already-visited route segments in that browser's memory, for that session only, and it does not follow the user to another device or another tab group. The consequence is the one worth stating out loud — anything that is specific to one signed-in user must not end up in the shared server layers, or you risk showing one person's page to another.
go deeper
Be able to say that some Next.js caching happens on the server and can serve many visitors, while the browser keeps its own copy of pages you already visited that nobody else can see.
Explain the keying: server layers are keyed by the request rather than the visitor, which is exactly why personalised content must not land in them.
Show the operational reading — everyone stale points at a shared server layer, one person stale and fixed by a reload points at the client — and treat personal data in a long-lived shared store as a retention concern, not just a correctness one.
Own the classification: which categories of content are allowed in shared layers at all, how that is enforced rather than remembered, and what review step catches a personalised route drifting into shared storage.
## Shared versus private Split the four layers by who can be served from them: - **Shared across everyone:** cached `fetch` responses on the server, and stored rendered output for statically rendered routes. Both are keyed by what was requested, not by who requested it, so any visitor whose request matches an entry can be handed that entry. - **Effectively private but not durable:** per-render memoization. It is on the server, but it exists only for the duration of one render of one request and is discarded immediately, so it can never serve a second visitor. - **Private to one browser:** the Router Cache. It lives in the JavaScript memory of the page the user has open, holding route segments they already visited so a soft navigation back is instant. Another user cannot see it, the same user on another device does not have it, and a full page reload discards it. ## Why the distinction is the first thing to learn Almost every caching mistake in a Next.js app is a mismatch between how personal a piece of content is and how shared the layer holding it is. Content that is the same for everyone — a marketing page, a product listing, a public article — belongs in the shared server layers, and that is precisely where they earn their keep: one render, one upstream call, thousands of visitors served. Content that differs per visitor — a dashboard showing your orders, a header greeting you by name — must not be stored in a layer that can hand the stored copy to somebody else. Getting that wrong is not a performance bug, it is a data-exposure bug, and it is the version of this question interviewers actually care about. ## How Next.js keeps you out of trouble The framework's defence is that reading anything request-specific — the incoming cookies, the request headers — makes a route render per request, so it has no stored output to share. That is why an authenticated page normally cannot be sitting in the shared output layer by accident: the act of reading the session forces per-request rendering. The defence is weaker one layer down. Cached `fetch` responses are keyed by the request you made upstream, and if you build a request that happens to include a user's token or ID, the entry you store is that user's data sitting in a shared store. It will not be handed to a different user, because a different user produces a different key and therefore a different entry — but the entries are still personal data living in a shared cache with a long life, which is a retention and blast-radius problem even when it is not a mix-up. ## What the private layer costs you instead Because the Router Cache is per-browser, its failure mode is the mirror image: not exposure, but staleness that only one person can see. A user mutates something, navigates back, and their browser re-renders the segment it captured before the change. Nobody else in the world observes the problem, which makes it easy to dismiss as a fluke and hard to reproduce from a fresh window. That asymmetry is a useful debugging tool. If exactly one person sees stale content and a reload fixes it, look at the client layer. If everyone sees the same stale content, look at the server layers. ## A minimal mental model ``` upstream API | (shared, server) cached fetch responses v render --(per render, server)-- memoized duplicate fetches | (shared, server) stored output for static routes v browser (private, in memory) visited route segments ``` Read that top to bottom and the ownership question answers itself: everything above the browser line is potentially serving strangers, and everything below it is serving exactly one person until they reload. ## What to say in an interview Name the split — two shared server layers, one private client layer, one that is scoped so tightly it serves nobody twice — and then volunteer the consequence rather than waiting to be asked: personal content must not be stored where an entry could be handed to another visitor, and Next.js's main protection is that reading per-request information forces the route to render per request.
- What goes wrong if a page personalised for the signed-in user ends up stored as shared route output?One visitor's rendered page can be served to another, which is a data-exposure bug rather than a performance one. In practice reading per-request information such as the incoming cookies makes the route render per request, so it has no shared stored output — but you should treat that as a property to verify, not to assume.
- Does the Router Cache follow a user to a second device?No. It is memory belonging to one browsing session on one device, so a second device, a second browser, or the same tab after a full reload all start with nothing. That is also why a stale-content report from exactly one person, fixed by reloading, points at the client layer rather than the server.
saying these in an interview costs you the question
- Thinks every Next.js cache is per user
- Assumes browser caching protects server-shared entries
- Believes a login makes caching automatically safe
- Calls per-render memoization a shared server cache