What is request memoization in Next.js? | Interview Question

Q: What is request memoization in Next.js?

**Target Audience:** Frontend engineers preparing for Next.js interviews — assumes basic React and App Router familiarity. **Difficulty:** Medium > **How to read this doc:** Each idea is explained in plain language first, then tagged with `📌 Interview term:`. Every behaviour claim was checked against the Next.js docs shipped with the package (written on 16.3.4, re-reviewed against 16.4.2) and, in the **Verified** section, against real output from a build or a running server; each Verified block names the version it ran on. ## 1. Why This Even Matters — A Story First A teacher asks three pupils in the same class to find today's date. Without memoization, all three walk to the office. With it, the first one goes, and the answer is written on the board for the other two. Tomorrow is a new lesson, the board is wiped, and the first pupil to ask walks to the office again. ## 2. The Core Idea 📌 **Interview term: Memoization** — returning the stored result of an identical call instead o

The problem

Question presented to candidate: "Three components on the same page each call fetch for the current user. How many network requests happen, and how would you get the same behaviour for a database query?"

What a strong answer should cover:

Next.js memoizes fetch GET requests with the same URL and options for the duration of one server render.
It applies across layouts, pages, Server Components, generateMetadata and generateStaticParams, but not in Route Handlers.
It is independent of the Data Cache: even no-store requests are deduplicated within a render.
For non-fetch work (ORM, SDK) wrap the function in React cache() to get the same per-request deduplication.
It resets for every request, so it is safe for per-user data.

Clarifying questions expected:

"Is it a fetch or a database call?" — only fetch is memoized automatically.
"Do the calls use exactly the same URL and options?" — any difference is a separate request.

Code / implementation expected: Yes — a React.cache-wrapped data function used in several components.

nextjs
request-memoization
fetch
caching

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Frontend engineers preparing for Next.js interviews — assumes basic React and App Router familiarity. Difficulty: Medium

How to read this doc: Each idea is explained in plain language first, then tagged with 📌 Interview term:. Every behaviour claim was checked against the Next.js docs shipped with the package (written on 16.3.4, re-reviewed against 16.4.2) and, in the Verified section, against real output from a build or a running server; each Verified block names the version it ran on.

1. Why This Even Matters — A Story First

A teacher asks three pupils in the same class to find today's date. Without memoization, all three walk to the office. With it, the first one goes, and the answer is written on the board for the other two. Tomorrow is a new lesson, the board is wiped, and the first pupil to ask walks to the office again.

2. The Core I

The solution is hidden so you can try first

5 min read · 8 sections

Read the code

A per-request cached loader used in several places

// lib/user.ts
import { cache } from "react";
import "server-only";
import { db } from "@/lib/db";

export const getUser = cache(async (id: string) => {
  return db.user.findUnique({ where: { id } }); // runs once per request per id
});

// app/layout.tsx and app/page.tsx and app/Header.tsx can all do:
//   const user = await getUser(session.userId);
// -> one database query per request

Discussion

Other approaches, follow-ups and how it went in real interviews.

Sign in to join the discussion.

No comments yet. Share how you would answer it.

The solution is hidden so you can try first

Keep your momentum going.