Next.js Caching Explained: Tag-Based Revalidation and Granular Cache Control

Next.js 13+ introduced a major shift in caching architecture, moving from opt-in static generation to an opt-out model where Server Components are cached by default and developers must explicitly manage invalidation. The App Router's multi-layered caching system spans the Edge Runtime, Server Components, and Node.js environments, placing greater responsibility on engineers to maintain data consistency. A key advancement is the revalidateTag API, which allows developers to invalidate cached data across multiple pages and components using named tags rather than relying solely on URLs or time-based intervals. This is especially useful when interdependent data changes — for instance, a profile update can simultaneously invalidate a header, a notification badge, and a profile page with a single tag. Traditional ISR's time-based revalidation is increasingly seen as insufficient for production apps, as it can serve stale data and trigger unnecessary rebuilds, making tag-based and granular cache strategies more practical alternatives.