In the Next.js App Router, what does passing `{ cache: 'force-cache' }` to `fetch` inside a Server Component do, and is that already what a plain `fetch` with no options does?

## The `fetch` in a Server Component is not the browser's `fetch` On the server, Next.js replaces the global `fetch` with its own wrapper. The wrapper still accepts everything the Web `fetch` accepts, and it reads two things to decide what to do with the response: the standard `cache` option, and a Next-only `next` option that carries `revalidate` and `tags`. Nothing about this applies in the browser — code that runs client-side gets the platform `fetch`, which ignores those hints entirely. ```ts // Server Component / server module const res = await fetch('https://api.example.com/products', { cache: 'force-cache', }) ``` ## What `force-cache` actually means here `force-cache` opts the request into the **Data Cache**: a server-side store of *fetch results*, persisted outside the lifetime of a single request. When a later request produces the same cache key, Next returns the stored body without going to the origin at all. Two consequences follow immediately. First, the store is **shared**. It is not per-user, per-session, or per-tab; it is one server-side store that every incoming request consults. Caching a response that differs per user is therefore a data-leak shape, not just a staleness bug. Second, an entry stays until something makes it stale. `force-cache` on its own sets no expiry — it is not a TTL. Staleness comes from `next: { revalidate: N }` on the same fetch, or from an on-demand invalidation elsewhere in the app. ## How the entry is keyed Next derives the key from the request URL and the options you passed — the method, the headers, and the body. That is why two fetches to the same URL with different `Authorization` headers do not collide, and why appending a query parameter is a valid way to force a distinct entry. It is also why a fetch that carries no per-user distinguishing input produces exactly one entry that every visitor shares. ## The default moved between major versions This is the part interviewers actually probe, because it is the single most common source of a stale answer. - **Next 13.4 – 14**: `fetch` in the App Router defaulted to `force-cache`. Data was cached unless you wrote `cache: 'no-store'` or triggered dynamic rendering some other way. Teams were routinely surprised by build-time data frozen into a page. - **Next 15 and later (including Next 16)**: `fetch` is **not** cached by default. You opt in with `cache: 'force-cache'` or by supplying `next: { revalidate: N }`. Teams upgrading are now surprised in the opposite direction — origin traffic climbs on pages nobody edited. The safest way to answer is to describe the *mechanism* ("which option puts this into the Data Cache, and what evicts it") and then name the version whose default you are quoting, rather than asserting a universal default. ```ts // Next 15/16: cached, because an option opts it in await fetch(url, { cache: 'force-cache' }) await fetch(url, { next: { revalidate: 3600 } }) // Next 15/16: not cached — no opt-in await fetch(url) ``` ## `no-store`, the other end of the same switch `cache: 'no-store'` states the opposite intent: do not read from the Data Cache and do not write to it. Under the Next 15+ default it is largely redundant for a plain fetch, but it is still worth writing on genuinely per-request data, because it documents the intent and it keeps behaving correctly if a surrounding configuration or a future default nudges things toward caching. ## Why it matters in practice Three recurring failures come out of misreading this option. 1. **Stale content that nothing seems to refresh.** On Next 14 defaults, a CMS fetch is cached at build and never revisited because no revalidation was configured. The fix is to give the fetch a lifetime, not to sprinkle `no-store` everywhere. 2. **An origin suddenly under load after an upgrade.** The same code that was implicitly cached now calls out on every render. The fix is to opt the genuinely shareable fetches back in deliberately. 3. **One user seeing another's data.** A per-user endpoint was opted in, and the key did not vary per user. The fix is to keep personal data out of the Data Cache entirely. A good answer names the store (Data Cache), names the opt-in (`force-cache` or `next.revalidate`), states what the key is built from, and pins the default to a version rather than claiming it as universal.