Caching is one of the most underrated features in the Next.js App Router. It allows you to keep your data fresh without constantly hitting your API. In one of my recent projects, I implemented a tag-based caching system for my server actions, simple enough to maintain, but flexible enough for production-grade data workflows.

In this article, I’ll walk you through how my caching works, what’s great about it, and what its current trade-offs are.

The Core Idea

Every data-fetching function (such as getAddresses, getOrders, or getProducts) includes a unique cache tag.

This tag tells Next.js how to cache the request and what to revalidate later when data changes.

Here’s the structure I use for defining tags:

// utils/tags.ts\nexport enum API_Tags {\n  ADDRESSES = \"addresses\",\n  PRODUCTS = \"products\",\n  ORDERS = \"orders\",\n}\n\nexport function getTag(name: API_Tags, listId?: string) {\n  return {\n    name,\n    default: name + (listId ?? \"LIST\"),\n    createTag: (id: string) => name + id,\n  };\n}\n\n

Each module then imports its tag definition, e.g.:

// tags/addresses.tag.ts\nimport { API_Tags, getTag } from \"@utils/tags\";\nexport const tag = getTag(API_Tags.ADDRESSES);\n\n

How Fetching Works

When fetching data, I attach the tag via the next fetch option:

export async function getAddresses() {\n  const response = await ServerApiClient.get(`/addresses`, {\n    next: { tags: [tag.default] },\n  });\n  return response.data;\n}\n\n

This tells Next.js:

“Cache this response and associate it with the addressesLIST tag.”

Now any page or component that uses getAddresses() automatically benefits from incremental caching.

The next request for this data is served directly from cache unless it’s explicitly revalidated.

How Revalidation Works

Whenever I perform a mutation (like creating, updating, or deleting an address), I manually revalidate the necessary tags:

revalidateTag(tag.default) // refreshes the full address list\nrevalidateTag(tag.createTag(id)) // refreshes a specific address\n\n

Example from my update action:

export async function updateAddress(id: string, state, formData) {\n  const response = await ServerApiClient.patch(`/addresses/${id}`, formData);\n\n  revalidateTag(tag.createTag(id)); // detail view\n  revalidateTag(tag.default);       // address list\n\n  redirect('/addresses');\n}\n\n

This ensures the cached list and any detail views stay consistent after an update.

The Pros

1. Predictable and Explicit

I know exactly which parts of my cache will be revalidated after each mutation. There’s no hidden magic.

2. Fast Subsequent Loads

Repeated visits to address pages or lists are nearly instant because the data is served from Next.js’ cache.

3. Scoped Invalidations

Since tags are modular (addresses, orders, products, etc.), revalidation doesn’t affect unrelated modules.

4. Works Seamlessly with Server Actions

This approach uses only built-in Next.js utilities like revalidateTag and redirect, meaning no external caching library is needed.

The Cons

1. List-Level Revalidation

Right now, I revalidate the entire list (tag.default) when one item changes.

That’s simple but slightly inefficient if the list is large.

2. No Automatic Dependency Tracking

Next.js doesn’t automatically infer which tags to revalidate based on the data returned, I have to manage that manually.

3. Server Context Limitation

Tag revalidation happens per deployment context. If you run multiple edge instances, each instance must revalidate separately.

Understanding Where the Cache Lives

A common misconception is that Next.js caching behaves like client-side caching (e.g., browser cache or React Query).

In reality, Next.js caches data on the server, not on the user’s machine.

When you use:

ServerApiClient.get<Pagination<User>>(url, { next: { revalidate: 6 * 3600, tags: [tag.default] } })\n\n

Next.js stores the result on the server. Every incoming request for that resource will reuse the same cached response — meaning all admins see identical data until the cache is revalidated.

This server-level caching is shared and consistent. It’s particularly useful for admin dashboards or reporting pages where data doesn’t need to change per user session.

⚡ Manual vs Time-based Revalidation

Initially, it might feel intuitive to use time-based revalidation (e.g., every 6 hours) to keep the data fresh.

However, because your user list is cached globally, a manual revalidation approach is cleaner and more efficient.

Instead of:

{ next: { revalidate: 6 * 3600, tags: [tag.default] } }\n\n

You can rely on:

revalidateTag(tag.default)\n\n

right after a user registers or updates their profile. This ensures:

Every admin view of /users immediately reflects the change.
No unnecessary re-fetching or wasted cache refresh cycles.
Predictable and controlled cache invalidation.

✅ Why This Matters

By shifting to manual revalidation, you:

Eliminate stale user data entirely.
Reduce server overhead from periodic revalidation.
Maintain cache accuracy without relying on arbitrary time windows.

In other words — you revalidate only when it actually matters.

Known Limitations (and Future Ideas)

The biggest limitation in Next.js today is that tags must be defined at fetch time.

You can’t dynamically add new tags after the data loads. This means there’s no first-class way to invalidate individual list items unless you already know their IDs.

To work around this, I stick to a two-level tag structure:

tag.default → for list data
tag.createTag(id) → for item-specific data (when available)

A future enhancement could include:

A registry to track fetched item IDs and revalidate them selectively.
Or, a hybrid tag system per page (e.g. addresses:page-1, addresses:page-2).

Summary

This caching approach strikes a good balance between simplicity and control.

It doesn’t over-engineer cache invalidation, yet gives you all the levers you need to keep server data fresh and consistent.

As Next.js continues to evolve its caching APIs, this system can scale naturally — whether you add dynamic tag registration, per-page invalidation, or even merge it with SWR for client-side hydration.

If you’re building a data-heavy application with server actions, this is a pattern worth adopting, it’s stable, predictable, and plays nicely with how the App Router expects you to think about data.