How do the different Next.js caches and revalidation layers work?
Assesses fundamental understanding of Next.js conventions, runtime behavior, and memory/performance considerations.
Hiring managers look for precision, avoidance of ambiguous jargon, and ability to explain trade-offs under real production conditions.
Next.js has several cache layers. The Data Cache stores individual fetch results and can be tagged. The Full Route Cache stores rendered HTML and RSC payloads for static routes at build time. The Router Cache holds prefetched segments in the browser. Request memoisation deduplicates identical fetches within one render.
fetch is cached by default in the App Router; cache: 'no-store' or export const dynamic = 'force-dynamic' opts a segment out. Time-based revalidation uses next: { revalidate: 60 }. On-demand revalidation uses revalidatePath or revalidateTag from a Server Action or route handler after a mutation.
revalidateTag('posts');
revalidatePath('/blog');
Routes that call dynamic functions such as cookies(), headers() or searchParams become dynamic automatically. Getting this wrong produces stale data (too much caching) or slow, expensive renders (too little). Segment config plus unstable_noStore() gives finer control, and revalidateTag is essential right after writes.
Candidate Response Strategy & Interview Tips
- Start with a concise one-sentence summary: Deliver a direct, confident answer first before expanding into nuances.
- Demonstrate real-world trade-offs: Discuss where this approach excels and when you would avoid it in production systems.
- Discuss complexity & edge cases: Proactively explain time/space complexity or boundary conditions (null values, scale limits).
- Prepare for interviewer follow-ups: Technical hiring panels frequently probe deeper into concurrency, backward compatibility, or alternative libraries.