Recommended App Router pattern to fetch shared data once for child routes

WHAT THIS TESTS: This question tests whether you understand the App Router layout architecture and server-side data deduplication. Interviewers want to see that you know layouts cannot pass arbitrary props to their children, and that you know the modern replacement for layout-level data fetching is request-scoped caching rather than prop drilling or client state.

A GOOD ANSWER COVERS: First, explicitly state that in the App Router a layout receives children as a prop but cannot pass custom props down to page components, which rules out fetching in the layout and handing data to nested routes. Second, describe the correct pattern: create a shared async helper that fetches the user data and wrap it with the React cache function so the function memoizes its return value for the duration of the request. Third, explain that you then call this cached function directly inside both the dashboard layout and any nested page Server Components that need the data. Fourth, note that because React deduplicates cached function calls during a single render pass, the underlying query executes exactly once even though it is invoked in multiple components. Fifth, mention that native fetch requests are automatically deduplicated by Next.js when the URL and options match, but for database clients or ORM queries you must use cache explicitly. Finally, emphasize keeping the fetch server-side and avoiding unnecessary Client Component boundaries.

COMMON WRONG ANSWERS: The most common mistake is saying you will fetch the user data in the layout and pass it down to pages as props. This reveals a Pages Router mental model because App Router layouts do not support prop drilling to children. Another red flag is suggesting getServerSideProps or getStaticProps, which do not exist in the App Router. Proposing a client Context provider in the layout that fetches with useEffect is also incorrect because it moves work to the browser, creates a waterfall, and increases bundle size. Similarly, fetching only in the layout and trying to access the result through a global variable or closure from child pages breaks streaming and parallel route rendering.

LIKELY FOLLOW-UPS: The interviewer may ask how you would expose this data to a Client Component nested inside a page, which is when you would pass it as a prop across the server-client boundary or use a lightweight store. They might also ask about the difference between React cache and Next.js unstable_cache, or how this pattern behaves under partial prerendering and dynamic rendering. Another follow-up is how you would refresh this data after a mutation, which leads to revalidatePath or cache invalidation strategies.

ONE CONCRETE EXAMPLE: Imagine a dashboard at app/dashboard/layout.tsx and nested pages at app/dashboard/settings/page.tsx and app/dashboard/billing/page.tsx. You create a file lib/getUser.ts that exports a getUser constant assigned to cache wrapping an async function that calls prisma.user.findUnique with the current user id. In the layout you await getUser to render a sidebar avatar. In settings/page.tsx you await getUser again to populate a profile form. During the request both components call getUser, but the cached Prisma query executes only once. If you later add a new nested route, you import the same helper without touching the layout.