How would you design auth for ISR pages without losing cache benefits?

What's really being asked

The interviewer is checking whether you understand that ISR is built for shared anonymous caches and that authentication introduces user-specific data which must not be stored in a shared CDN tier. They want to see a layered architecture that keeps the static shell edge-cached while isolating personalized fragments to private or client-side layers.

The full answer

First, state that a fully personalized ISR page cannot safely be cached in a shared edge cache because it would leak data across users. Second, propose serving a static ISR shell to all visitors and deferring personalization to client components that fetch from Route Handlers, or to dynamic server components that use cookies or headers and therefore opt out of static generation for that specific subtree. Third, explain that you can inspect cookies or headers to decide whether to render the cached shell or trigger a dynamic branch. Fourth, separate revalidation concerns: public content uses revalidate or revalidateTag on a long interval, while private data bypasses shared caching entirely. Fifth, note that in the App Router, calling cookies or headers automatically marks the route as dynamic, so you should isolate those calls inside a parallel route or nested layout to preserve ISR for the outer shell.

The mistakes people make

A critical red flag is suggesting getServerSideProps for the entire page or calling cookies at the top level of an ISR page, which forces SSR for every request and destroys cache hit ratios. Another error is trying to cache personalized HTML at the edge keyed by session cookie, which fragments the cache and creates security vulnerabilities. Some candidates also conflate ISR with pure client-side rendering and propose abandoning static generation altogether.

What usually comes next

The interviewer may ask how you would refresh an auth token without blocking the static shell, or how to revalidate private data after a user mutation. They might also ask about trade-offs between client-side fetching versus dynamic server components, or how to use NextRequest and the edge runtime to rewrite unauthenticated users to the cached ISR variant while sending authenticated users to a fully dynamic route.

A concrete example

Consider a dashboard page. The layout, navigation, and footer are identical for everyone and generated via ISR with a five-minute revalidate window. When a request includes an auth cookie, a dynamic sidebar component that calls cookies and unstable_noStore fetches the user name and recent items from a Route Handler. The main shell is served from the edge cache for anonymous users, while authenticated users receive the same cached shell plus streamed dynamic fragments. On logout, the client clears state and the page falls back to the anonymous cached version without a full reload.