Caching needs a version number.

The version is part of the question

A framework API is not a timeless definition. Next.js ships evolving caching models, and advice that worked in one release may have different defaults or prerequisites in another. When you ask how to invalidate a cache, the first useful detail is the specific release and whether Cache Components are enabled.

In the Next.js 16.4.2 documentation, Cache Components can use the 'use cache' directive to mark work for caching. Tagging and revalidation are described through APIs such as cacheTag, revalidateTag and updateTag. Reading these features as one undifferentiated collection of caching tips can lead to code that is technically plausible but wrong for your application's configuration.

Two invalidation experiences

The official migration guidance describes two distinct behaviors. revalidateTag can use a cache profile such as 'max' to mark tagged data stale while allowing a stale-while-revalidate experience. That can be a sensible choice for catalogues, editorial content or documentation: the user can continue reading while a fresh result is prepared.

updateTag is intended for an immediate read-your-own-writes experience after a Server Action. When someone edits a record and expects the next view to reflect their update, serving an old cached result—even briefly—may be the wrong product behavior. These are different user expectations, not merely different function names.

The relevant documentation also distinguishes where the APIs can run. In particular, updateTag belongs in a Server Action. revalidateTag supports Server Actions and Route Handlers. Always verify these requirements in the version you deploy.

• Identify the exact Next.js version and whether you use Cache Components.
• Define whether stale-while-revalidate is acceptable for the route.
• Choose a cache tag that represents the data being updated, not an unrelated page.
• Check where the chosen invalidation call is permitted.
• Test the read path after mutation rather than relying on a function name.

An example worth reading carefully

The following excerpt illustrates a tagged invalidation decision in a Server Action. The real mutation would happen before revalidation, and the tag would need to match the cached data. It is intentionally a narrow example, not a complete persistence implementation.

'use server'

import { revalidateTag } from 'next/cache'

export async function publishArticle() {
  // Save the article in your own data store first.
  revalidateTag('articles', 'max')
}

Documentation, not memory, should settle the details

The useful habit is to resolve the framework, select the deployed release, ask one focused question, and inspect the answer's source. If the question concerns immediate invalidation, consult the migration and API reference pages together. If it concerns rendering and prerendering, review Cache Components rather than assuming earlier App Router defaults.

Version-specific retrieval is not bureaucratic overhead. It is a way to avoid implementing yesterday's solution against today's interface. The repository's code and the versioned official docs should agree before you ship.