Discuss Request Memoization caching mechanism?
Next.js extends the fetch API to automatically memoize requests that have the same URL and options.
- 1
While rendering a route, the first time a particular request is called, its result will not be in memory and it'll be a cache MISS.
- 2
Therefore, the function will be executed, and the data will be fetched from the external source, and the result will be stored in memory.
- 3
Subsequent function calls of the request in the same render pass will be a cache HIT, and the data will be returned from memory without executing the function.
- 4
Once the route has been rendered and the rendering pass is complete, memory is 'reset' and all request memoization entries are cleared.
- 1
Request memoization is a React feature, not a Next.js feature. It's included here to show how it interacts with the other caching mechanisms.
- 2
Memoization only applies to the GET method in fetch requests.
- 3
Memoization only applies to the React Component tree, this means:
- 4
It applies to fetch requests in generateMetadata, generateStaticParams, Layouts, Pages, and other Server Components.
- 5
It doesn't apply to fetch requests in Route Handlers as they are not a part of the React component tree.
- 6
For cases where fetch is not suitable (e.g. some database clients, CMS clients, or GraphQL clients), you can use the React cache function to memoize functions.
- 7
Since the memoization is not shared across server requests and only applies during rendering, there is no need to revalidate it.
Scenario Questions
0-2 years experience
- 1In a Next.js page that uses getServerSideProps, how would you add memoization so the same API call isn’t made twice when the query parameters are identical?
- 2If you memoize a fetch request but the data on the server changes, what will the user see and how can you keep the UI fresh?
- 3What pitfalls arise if you use React's useMemo to cache the result of an async fetch inside a component?
2-5 years experience
- 1You added request memoization to a product‑listing page, but after release some users still see old product info after an update. Walk me through how you’d debug and resolve it.
- 2Explain the trade‑offs between using Next.js’s built‑in revalidate cache versus a custom in‑memory memoization layer for user‑specific API calls.
- 3During a load test the memoization cache grew without bound and caused memory pressure. How would you detect this in production and what mitigation would you apply?
5-8 years experience
- 1Design a request memoization strategy for a Next.js app that serves both public SSR pages and authenticated API routes, covering cache keys, invalidation, and edge‑runtime constraints.
- 2How would you implement request deduplication across Vercel serverless functions so that simultaneous identical requests trigger only one backend call?
- 3What testing approach would you use to verify both correctness and performance of your memoization layer under high traffic, and which metrics would you monitor?
8+ years experience
- 1Your team is migrating a monolithic Next.js codebase to a micro‑frontend architecture. How would you evolve the existing request memoization so it works across multiple teams without causing cache fragmentation?
- 2What long‑term policies would you establish for cache eviction, versioning, and observability to prevent stale‑data bugs across several services?
- 3If you need to support both edge functions and traditional Node.js servers, how would you abstract the memoization layer to be portable and performant, and what trade‑offs would you accept?
Follow-up Questions
- What metrics would you watch to know the cache is working as intended?
- How does the choice of cache location affect latency and scalability?
- Can you describe a scenario where memoization could introduce a bug?