In a Next.js App Router Server Component, a developer adds `cache: 'force-cache'` to a fetch of an endpoint that returns the signed-in user's own profile. Why is that dangerous, and what decides whether two different visitors hit the same cached entry?

## The store is shared, and that is the whole point The Data Cache exists so that work done for one request can be reused by the next one — across users, across sessions, across renders. There is no ambient notion of "the current user" attached to an entry. When you write `cache: 'force-cache'`, you are saying *this response is a fact about the world, not about the caller*. Most caching bugs are about freshness. This one is about audience, and it is much more expensive. ## What the key is built from Next derives the entry key from the request URL and the options handed to `fetch` — the method, the headers, the body. Nothing else. Notably, the ambient request context does not silently join the key: a Server Component does not automatically forward the incoming request's cookies to an outbound fetch, so unless you explicitly attached something identifying, two visitors produce byte-identical keys. ```ts // Same key for every visitor: identity is nowhere in the URL or options. const me = await fetch('https://api.example.com/me', { cache: 'force-cache' }) ``` Walk it through: visitor A renders, the endpoint returns A's profile, the entry is written. Visitor B renders a minute later; the key matches; B is served A's profile without a single request leaving the server. Nothing errors, nothing logs, and in an internal tool the bug can live for months because it only shows when two people compare screens. ## "Then I'll put the token in a header" Adding an `Authorization` header does change the key, so the collision goes away. But look at what the cache now holds: one entry per user, for a response that is typically read once per session and is stale the moment the user edits their profile. You have converted a shared cache into a per-user store with no eviction policy you control, which is a poor use of a resource whose value comes from being shared. There is a second-order version of the same mistake with any per-request header — a request ID, a trace header, a locale that varies widely. Each distinct value forks a new entry, the hit rate collapses, and the cache grows while doing nothing useful. ## What to do instead Split the fetches by audience, not by convenience: - **Shared, non-personal data** — catalogues, published content, configuration, reference data — opts in with `force-cache` or a `revalidate` interval. It is the same for everyone, so sharing it is correct. - **Personal or authorisation-dependent data** — profiles, carts, entitlements, anything the answer changes with who is asking — stays out of the Data Cache. Under Next 15 and 16 defaults leaving the options off already achieves that, and writing `cache: 'no-store'` states the intent for the next reader. A page usually needs both, and that is fine: the shared parts are cached, the personal parts are not, and they compose in the same render. ## How to catch it - In review, treat `force-cache` on any URL containing `me`, `account`, `session`, `cart`, or `admin` as something to justify out loud. - Ask of each cached fetch: *if I served this exact bytes to a stranger, would that be fine?* If the answer is no, it does not belong in a shared cache. - When a report of "I saw someone else's name" arrives, the shared-key hypothesis is worth checking before session handling, because it is silent and it survives restarts of the process that first cached it. ## The one-line version The Data Cache is keyed by the request you made, not by the user you made it for. Anything whose correct answer depends on who is asking must not be opted into it.