How do you opt out of static rendering for real-time data?

WHAT THIS TESTS: This question probes whether you understand the difference between the Full Route Cache, the Data Cache, and the Router Cache in Next.js App Router. Seniors should know that static generation is the default, and that opting out requires explicit segment-level or fetch-level configuration. It also checks if you can balance freshness against server load and CDN efficiency.

A GOOD ANSWER COVERS: A good answer hits four strategies in order. First, route segment config: export const dynamic equals force-dynamic or export const revalidate equals zero at the page level to opt the entire segment out of static rendering and force SSR on every request. Second, incremental static regeneration with a low revalidate value such as one to thirty seconds, which keeps a cached fallback but refreshes it in the background; this reduces load but tolerates brief staleness. Third, data cache control: using unstable_noStore inside components or passing cache no-store to fetch to keep the page shell static while making the data dynamic. Fourth, client-side architecture: using SWR or React Query in a client component, or Server-Sent Events, to pull truly real-time ticks after hydration so the server is not blocked by frequent renders. For each, you should weigh TTFB, server CPU, cache hit ratio, and cost.

COMMON WRONG ANSWERS: Red flags include suggesting random query parameters to bust caches, which breaks CDN optimization and hurts SEO. Another mistake is recommending revalidatePath or revalidateTag as the primary fix without explaining that these are on-demand invalidations triggered by mutations, not a continuous refresh strategy. Confusing the Data Cache with the Full Route Cache is also common: disabling fetch cache does not automatically make a statically generated page dynamic if the route segment itself is still cached. Finally, proposing no-store everywhere without discussing the resulting database or API load shows a lack of operational thinking.

LIKELY FOLLOW-UPS: Interviewers often push on how you would handle five thousand concurrent users if every request is SSR. They may ask how you would combine short ISR with on-demand revalidation via webhooks from the stock exchange. Another angle is PPR: which parts of the stock page could be static shell versus streaming dynamic content. You might also be asked to compare App Router solutions against the Pages Router approach using getServerSideProps.

ONE CONCRETE EXAMPLE: Imagine a stock detail page at app slash stocks slash ticker. If the ticker price must update within one second but the company description is static, you would export const dynamic equals force-dynamic only if the entire page must be server-rendered. A better approach is to keep the page static with a thirty-second revalidate and render the live price in a client component that polls an API route every second. The API route uses unstable_noStore and streams the latest quote. This gives you a fast cached shell, minimal server load for the static parts, and real-time data where it matters.