Describe an ideal ISR scenario and configure it in a Server Component

WHAT THIS TESTS: The interviewer wants to know if you understand rendering strategy tradeoffs in the Next.js App Router, specifically when Incremental Static Regeneration outperforms static generation, server-side rendering, or client-side fetching. They are also checking whether you know the practical configuration mechanics for Server Components, where data fetching happens directly inside the component rather than in a lifecycle hook or a separate API route.

A GOOD ANSWER COVERS: First, identify a realistic semi-static scenario. Good examples include an e-commerce product listing page, a news homepage, or a documentation index where content updates periodically but does not need to be real-time. The key criteria are that the data changes often enough to make a pure static build stale, but not so frequently that SSR or client fetching is justified. Second, explain the two primary configuration methods in a Server Component. The first method is using the native fetch API with a revalidate option, for example passing an object with next set to an object containing revalidate with a numeric value like 60, which tells Next.js to cache the response for sixty seconds and regenerate it in the background. The second method is exporting a route segment config such as export const revalidate = 60 from the page file, which applies to all fetches in that segment that do not have their own revalidate value. Third, mention that ISR in the App Router works via stale-while-revalidate behavior: the first visitor after the revalidation window triggers a background refresh, and subsequent visitors get the updated static page without waiting. Fourth, note that this only applies to the build output or the static rendering path; if the segment is forced dynamic, ISR behavior does not apply.

COMMON WRONG ANSWERS: A major red flag is suggesting useEffect or a client-side data fetching library inside a Server Component to achieve ISR. Server Components cannot use hooks like useEffect. Another red flag is confusing ISR with SSR by saying the page regenerates on every request. Some candidates also forget to specify the revalidate unit in seconds or claim that ISR requires getStaticProps, which is a Pages Router pattern and does not exist in the App Router. Finally, saying ISR is ideal for real-time dashboards or user-specific data shows a misunderstanding of caching semantics.

LIKELY FOLLOW-UPS: The interviewer may ask how on-demand revalidation differs from time-based revalidation, which would require mentioning revalidatePath or revalidateTag. They might also ask what happens if the background regeneration fails, in which case the old static page continues to be served. Another common follow-up is how ISR interacts with dynamic segments and generateStaticParams, or how caching works when fetch is wrapped in a third-party library that does not expose the native fetch options.

ONE CONCRETE EXAMPLE: Imagine a large online retailer with ten thousand product category pages. Building all pages at build time takes thirty minutes, and inventory prices update every five minutes. Using ISR, you set the fetch call inside the Server Component to use next revalidate with a value of 300. At build time, the most popular categories are pre-rendered. When a shopper visits a less popular category, Next.js serves a stale version and triggers a background regeneration. After five minutes, the next shopper sees refreshed pricing without the server hitting the database on every request. This balances performance and freshness.