## Understanding Caching in Next.js Caching is probably one of the most misunderstood parts of [Next.js](/courses/nextjs). Mostly because [Next.js](/courses/nextjs) caching has changed **a lot** over the last few versions. If you learned Next.js 14, you probably heard: ```text "Next.js caches everything aggressively." ``` Then you open modern Next.js and see: ```text "use cache" cacheLife() cacheTag() updateTag() revalidateTag() Partial Prerendering ``` and suddenly your old mental model starts filing for retirement. 😭 So let's understand this properly. --- # What Is Caching? Caching means: > Save the result of expensive work so you don't have to repeat that work every time. Imagine your database query takes: ```text 300ms ``` and returns the same list of courses for thousands of users. Without caching: ```text User 1 ↓ Database query User 2 ↓ Database query User 3 ↓ Database query User 10,000 ↓ Database is reconsidering its career choices ``` With caching: ```text First request ↓ Run query ↓ Store result ↓ Future requests ↓ Reuse cached result ``` Much faster. Less database load. Lower infrastructure cost. --- > **Definition: Cache** > > A cache stores previously computed data or rendered output so it can be reused instead of recomputed every time. --- # Important: The Next.js Caching Model Changed Older [Next.js App Router](/courses/nextjs) documentation taught **four main caching mechanisms**: ```text 1. Request Memoization 2. Data Cache 3. Full Route Cache 4. Router Cache ``` That model is still extremely useful because: - Many Next.js 13–15 projects use it - You'll still see it in interviews - Existing tutorials teach it - Existing codebases use `force-cache` - Existing codebases use `next.revalidate` - Existing codebases use route-level `revalidate` But modern Next.js 16 introduced a newer model called: ```text Cache Components ``` The modern approach is more explicit: ```text "Cache this specific work." ``` instead of: ```text "Figure out which of four invisible caches is doing something behind my back." ``` Much nicer. 😄 --- # The Two Mental Models You should understand both. ### Previous Model ```text Request Memoization Data Cache Full Route Cache Router Cache ``` ### Modern Next.js ```text Request Memoization + "use cache" + cacheLife() + cacheTag() + Revalidation + Static Shell + Suspense / Streaming + Prefetching ``` We'll start with the **modern system**. Then we'll learn the classic four-cache architecture so older code doesn't look like ancient runes. --- # Enabling Cache Components Modern Next.js caching uses: ```text Cache Components ``` Enable it inside: ```text next.config.ts ``` or: ```text next.config.mjs ``` Example: ```js const nextConfig = { cacheComponents: true, } export default nextConfig ``` Now you can explicitly mark reusable server work using: ```js "use cache" ``` --- # The Modern Mental Model Think about your page in three categories: ```text STATIC ↓ Can be prepared ahead of time ``` ```text CACHED ↓ Expensive work whose result can be reused ``` ```text REQUEST-TIME ↓ Needs fresh/user-specific data ``` One route can contain all three. For example: ```text Product Page │ ├── Header │ ↓ │ STATIC │ ├── Product Details │ ↓ │ CACHED │ ├── Reviews │ ↓ │ CACHED + REVALIDATED │ └── Your Cart ↓ REQUEST-TIME ``` This is one of the biggest improvements in modern Next.js. --- # 1. Request Memoization Let's start with something that still exists in modern Next.js. Imagine two components need the same user. ```jsx async function Navbar() { const response = await fetch( "https://api.example.com/me" ) const user = await response.json() return ( ) } ``` Then another component does the exact same fetch: ```jsx async function Profile() { const response = await fetch( "https://api.example.com/me" ) const user = await response.json() return (

{user.name}

) } ``` You might expect: ```text 2 identical network requests ``` But [React](/courses/reactjs) automatically memoizes identical `fetch()` calls during the same rendering work. Conceptually: ```text Navbar ↓ fetch("/me") ↓ Real request ``` then: ```text Profile ↓ fetch("/me") ↓ Reuse memoized result ``` --- > **Definition: Request Memoization** > > Request Memoization temporarily deduplicates identical `fetch()` requests during a [React](/courses/reactjs) server render so the same request doesn't need to execute repeatedly. --- # Important: Memoization Is NOT Persistent Caching This is crucial. Request Memoization lasts roughly for the current server rendering work. Then it's gone. Think: ```text Request #1 ├── fetch user ├── reuse user └── memoization cleared ``` Then: ```text Request #2 ├── fetch user again └── new memoization ``` So: ```text Request Memoization ≠ Persistent Cache ``` It solves: ```text Duplicate work inside one render ``` not: ```text Reuse data across thousands of users ``` --- # Why Request Memoization Is Useful Without memoization you might feel forced to fetch data at the top: ```jsx const user = await getUser() ``` Then you're prop-drilling purely to avoid duplicate requests. With memoization, components can fetch the data closer to where they need it. That makes composition much easier. --- # Request Memoization Only Applies Automatically to `fetch()` If you're doing: ```js fetch(...) ``` identical requests are memoized automatically during rendering. But what about: ```js db.user.findUnique(...) ``` ? React doesn't automatically know those two database calls are the same operation. --- # Deduplicating Database Queries with React `cache()` Use: ```js cache() ``` from React. Example: ```js import { cache } from "react" export const getUser = cache(async id => { return db.user.findUnique({ where: { id } }) }) ``` Now: ```js getUser("123") ``` called multiple times during the same render can reuse the result. Example: ```jsx const user = await getUser("123") ``` from several components. --- # `cache()` vs `"use cache"` These look similar. They are NOT the same thing. ### React `cache()` ```js cache(fn) ``` primarily helps deduplicate work during rendering. Think: ```text Same render ↓ Don't repeat same call ``` --- ### Next.js `"use cache"` ```js "use cache" ``` creates reusable cached output that can survive beyond a single render according to its cache lifetime. Think: ```text Across renders/users ↓ Reuse result ``` So: ```text React cache() = Memoization ``` ```text "use cache" = Persistent/reusable Next.js caching behavior ``` Different problems. --- # 2. Data-Level Caching with `"use cache"` Now imagine: ```js db.product.findMany() ``` takes: ```text 300ms ``` and every visitor sees the same product catalog. We probably don't need to query the database on every request. Create: ```js export async function getProducts() { "use cache" return db.product.findMany() } ``` Now Next.js knows: > "The output of this [function](/javascript/functions-in-javascript) is reusable." --- # Add `cacheLife()` You should normally define how long the cached result is useful. Example: ```js import { cacheLife } from "next/cache" export async function getProducts() { "use cache" cacheLife("hours") return db.product.findMany() } ``` Now your mental model becomes: ```text getProducts() ↓ Cache result ↓ Reuse it ↓ Refresh according to cache lifetime ``` --- > **Definition: `cacheLife()`** > > `cacheLife()` tells Next.js how long cached content can remain fresh, when it should be revalidated, and when it should expire. --- # Built-In Cache Profiles Modern Next.js provides profiles such as: ```text seconds minutes hours days weeks max ``` Example: ```js cacheLife("hours") ``` or: ```js cacheLife("days") ``` The exact profile contains three concepts: ```text stale revalidate expire ``` --- # What Does `stale` Mean? Imagine cached data is: ```text 5 minutes old ``` but still acceptable for instant client navigation. The: ```text stale ``` window controls how long the client can treat cached content as fresh enough for navigation behavior. --- # What Does `revalidate` Mean? This controls when Next.js should start refreshing the cached result. Think: ```text Cached result ↓ Revalidation window reached ↓ Fresh work can run ``` --- # What Does `expire` Mean? Eventually cached content becomes too old to reuse. That's: ```text expire ``` After that point Next.js needs fresh content before serving the result again. --- # Custom Cache Lifetime You can configure your own values: ```js "use cache" import { cacheLife } from "next/cache" export async function getProducts() { cacheLife({ stale: 3600, revalidate: 7200, expire: 86400, }) return db.product.findMany() } ``` Conceptually: ```text stale → 1 hour revalidate → 2 hours expire → 1 day ``` You usually don't need custom numbers for everything. Built-in profiles are easier. --- # What Should You Cache? Good candidates: ```text Blog posts Course chapters Product catalog Documentation Public profile data CMS content Categories Site configuration Expensive calculations ``` Basically: > Can multiple users safely share this result for some amount of time? If: ```text Yes ``` it's a caching candidate. --- # What Should You NOT Cache Globally? Be careful with: ```text Current user's bank balance Private dashboard Shopping cart Session Personal notifications Request-specific authorization ``` You don't want: ```text Asif's dashboard ``` being cached and shown to: ```text Sara ``` That would be a very memorable production incident. 💀 --- # 3. UI-Level Caching `"use cache"` doesn't only work with data [functions](/javascript/functions-in-javascript). You can cache entire components. Example: ```jsx import { cacheLife } from "next/cache" async function PopularCourses() { "use cache" cacheLife("hours") const courses = await db.course.findMany({ where: { popular: true } }) return (

{course.title}

) } ``` Now both: ```text Data + Rendered component output ``` can participate in the cached/static shell architecture. --- # Caching an Entire Page You can even cache an entire page when appropriate: ```jsx import { cacheLife } from "next/cache" export default async function Page() { "use cache" cacheLife("hours") const posts = await db.post.findMany() return ( ) } ``` This is useful when the entire result can safely be shared. --- # But Don't Cache More Than Necessary Imagine: ```text Dashboard │ ├── Public Announcements └── User Account Balance ``` Don't cache the entire dashboard just because announcements are cacheable. Instead: ```text Dashboard │ ├── CachedAnnouncements │ ↓ │ "use cache" │ └── AccountBalance ↓ Request-time ``` Cache at the smallest useful boundary. --- # 4. Cache Keys Suppose: ```js getProduct("iphone") ``` and: ```js getProduct("macbook") ``` both use: ```js "use cache" ``` Next.js needs separate entries. Arguments automatically contribute to the cache key. Conceptually: ```text getProduct("iphone") ↓ Cache Entry A ``` ```text getProduct("macbook") ↓ Cache Entry B ``` So: ```js async function getProduct(id) { "use cache" return db.product.findUnique({ where: { id } }) } ``` works naturally with different IDs. --- # 5. Cache Tags Caching is easy. The real headache usually starts here: > "Okay... how do I update the cache when something changes?" That's where: ```js cacheTag() ``` comes in. Example: ```js import { cacheLife, cacheTag } from "next/cache" export async function getProducts() { "use cache" cacheLife("hours") cacheTag("products") return db.product.findMany() } ``` Now that cache entry has a label: ```text products ``` --- > **Definition: Cache Tag** > > A cache tag is a label attached to cached data so related cache entries can later be invalidated together. --- # Why Tags Are Powerful Imagine product data appears on: ```text / /products /search /categories/laptops /dashboard ``` Instead of thinking: ```text Which 5 URLs do I need to clear? ``` think: ```text What DATA changed? ``` Answer: ```text products ``` So you invalidate: ```text products ``` wherever it is used. Much cleaner. --- # Dynamic Tags You can also tag individual resources. Example: ```js async function getProduct(id) { "use cache" cacheTag( `product:${id}` ) return db.product.findUnique({ where: { id } }) } ``` Now: ```text product:123 ``` and: ```text product:456 ``` can be invalidated independently. --- # 6. `revalidateTag()` Suppose an administrator updates your product catalog. You can tell Next.js: ```js revalidateTag( "products", "max" ) ``` Example: ```js "use server" import { revalidateTag } from "next/cache" export async function updateProduct( id, data ) { await db.product.update({ where: { id }, data }) revalidateTag( "products", "max" ) } ``` Modern: ```js revalidateTag(tag, "max") ``` uses **stale-while-revalidate** behavior. --- # Stale-While-Revalidate Think: ```text Cached version exists ↓ Data becomes stale ↓ User receives stale version immediately ↓ Fresh version generated in background ↓ Future visitors receive fresh data ``` This is great for things such as: ```text Blog posts Product catalogs News lists Course lists ``` where being a few seconds behind is okay. --- # Why Serve Stale Data? Because sometimes: ```text Instant slightly-old content ``` is better than: ```text Blank screen waiting for fresh content ``` For example: ```text Product description changed ``` from: ```text 16 GB RAM ``` to: ```text 18 GB RAM ``` It may be acceptable for one visitor to briefly see the previous cached value while the new result refreshes. --- # 7. `updateTag()` But sometimes stale data is NOT acceptable. Imagine: ```text User edits profile name ``` from: ```text Asif ``` to: ```text Asif Imam ``` Then after clicking Save, the profile still says: ```text Asif ``` for another 30 seconds. User: > "Did it save or did I hallucinate the button click?" 😭 For this situation, use: ```js updateTag() ``` --- # Example ```js "use server" import { updateTag } from "next/cache" export async function updateProfile( userId, data ) { await db.user.update({ where: { id: userId }, data }) updateTag( `user:${userId}` ) } ``` `updateTag()` immediately expires the tagged cache. --- # `updateTag()` vs `revalidateTag()` This distinction is important. ```text updateTag() ``` means: > "This user just changed something. They should immediately see the new value." Think: ```text Read-your-own-writes ``` --- ```text revalidateTag() ``` means: > "Refresh this cached content, but stale content can temporarily be served." Think: ```text Background refresh ``` --- # Comparison | API | Behavior | Good For | |---|---|---| | `updateTag()` | Immediately expires cached data | User should instantly see own changes | | `revalidateTag(tag, "max")` | Stale-while-revalidate | Background content refresh | Important: ```text updateTag() ``` can only be used from: ```text Server Actions ``` while: ```text revalidateTag() ``` can also be used from Route Handlers. --- # 8. `revalidatePath()` Sometimes you don't know which cache tags are involved. You simply know: ```text /dashboard ``` needs refreshing. Use: ```js revalidatePath() ``` Example: ```js "use server" import { revalidatePath } from "next/cache" export async function updateSettings( formData ) { await saveSettings( formData ) revalidatePath( "/dashboard" ) } ``` This invalidates cached data associated with that route. --- # Tags vs Paths Think: ```text cacheTag ↓ "What DATA changed?" ``` versus: ```text revalidatePath ↓ "What ROUTE needs refreshing?" ``` Tags are usually more precise. --- # Preferred Modern Approach If possible: ```text Cache data ↓ Tag data ↓ Invalidate the data tag ``` instead of: ```text Something changed ↓ Nuke entire page cache ``` Precision is nice. Your cache appreciates not being carpet-bombed every time someone edits a username. 😭 --- # 9. Fresh Request-Time Data Now imagine you need: ```text Current stock price Current session User notifications Live inventory ``` You DON'T want caching. Simply don't use: ```js "use cache" ``` Example: ```jsx async function LiveInventory() { const inventory = await db.inventory.findMany() return ( ) } ``` This work happens at request time. --- # Use Suspense for Fresh Data Fresh data can take time. Instead of blocking the entire route: ```jsx import { Suspense } from "react" export default function ProductPage() { return ( <> Checking inventory...

} > ) } ``` Now: ```text Product Information ↓ Can be static/cached ``` while: ```text Live Inventory ↓ Runs fresh at request time ``` and streams in later. --- # This Is Partial Prerendering Modern Cache Components integrate with: ```text Partial Prerendering ``` or: ```text PPR ``` A route might become: ```text ┌─────────────────────────────┐ │ Navbar │ ← Static ├─────────────────────────────┤ │ Product Information │ ← Cached ├─────────────────────────────┤ │ Reviews │ ← Cached ├─────────────────────────────┤ │ Live Inventory │ ← Streamed ├─────────────────────────────┤ │ User Cart │ ← Request-time └─────────────────────────────┘ ``` One page. Different caching behavior. 🔥 --- # Static Shell During prerendering, Next.js builds a reusable: ```text Static Shell ``` containing things such as: ```text Static components Cached components Suspense fallbacks ``` Then request-time content can stream into the holes. Example: ```text Initial Response Navbar Product Reviews Cart Skeleton ``` Then: ```text Request-time Cart Data ↓ Streams into Cart Skeleton ``` This is much more flexible than the old: ```text Entire route = static ``` or: ```text Entire route = dynamic ``` model. --- # 10. Client-Side Navigation and Prefetching Caching isn't only happening on the server. Next.js also optimizes navigation in the browser. When you write: ```jsx import Link from "next/link" Courses ``` Next.js can prefetch route information before the user clicks. Conceptually: ```text Link becomes visible ↓ Prefetch destination ↓ User clicks ↓ Useful UI already available ``` That's why App Router navigation can feel SPA-like. --- # Modern Partial Prefetching Modern Next.js 16.3 introduced a more advanced concept: ```text Partial Prefetching ``` When enabled: ```js const nextConfig = { cacheComponents: true, partialPrefetching: true, } export default nextConfig ``` Next.js can prefetch a reusable: ```text App Shell ``` for a destination route. --- # App Shell Example Suppose: ```text /store/[slug] ``` contains: ```text Store Layout Product Skeleton Inventory Skeleton ``` Next.js can prefetch the reusable shell before it knows the final product-specific data. Then: ```text Click product ↓ Shell appears instantly ↓ Product data streams in ``` This is part of modern **Instant Navigation**. --- # Browser Navigation Cache Mental Model Instead of thinking only: ```text "The Router Cache stores whole pages." ``` a better modern mental model is: ```text Next.js keeps reusable route and prefetched RSC/App Shell data in browser memory so client-side navigation can reuse work. ``` The exact client routing implementation has evolved across Next.js versions. The important result is: ```text No full page refresh + Shared layouts stay mounted + Prefetched UI can appear instantly + Remaining content can stream ``` --- # `` Prefetching By default, Next.js can prefetch eligible routes when: ```jsx ``` enters the viewport. Modern Partial Prefetching can fetch the reusable shell. For a specific link, you can explicitly request more aggressive prefetching: ```jsx Checkout ``` Use this intentionally. Prefetching 500 routes that nobody clicks is still wasted work. --- # 11. The Classic Four Caches Now let's cover the famous architecture you'll see in older Next.js material. This model was especially important in: ```text Next.js 13 Next.js 14 Next.js 15 ``` without modern Cache Components. The four mechanisms were: ```text 1. Request Memoization 2. Data Cache 3. Full Route Cache 4. Router Cache ``` You should know these for interviews and existing codebases. --- # Classic Cache 1: Request Memoization This part is still relevant. ```js fetch("/api/user") ``` called multiple times during one React render can be deduplicated. Conceptually: ```text Render ├── Navbar → fetch user ├── Sidebar → same fetch └── Page → same fetch ``` Network: ```text 1 request ``` not: ```text 3 requests ``` --- # Classic Cache 2: Data Cache The old Data Cache stored results of cached server data requests across incoming requests. Older code might use: ```js fetch( "https://api.example.com/products", { cache: "force-cache" } ) ``` or: ```js fetch( "https://api.example.com/products", { next: { revalidate: 60 } } ) ``` This is different from Request Memoization. --- # Request Memoization vs Data Cache ```text Request Memoization ↓ Same render only ``` ```text Data Cache ↓ Reusable across requests ``` Example: ```text Visitor A ↓ Network request ↓ Data Cache ``` Then: ```text Visitor B ↓ Reuse cached data ``` --- # Important Modern Change: `fetch()` Is NOT Cached by Default This is one of the biggest outdated claims in old Next.js tutorials. In Next.js 14: ```js fetch(url) ``` was commonly cached by default under the old caching architecture. Modern Next.js changed this. Now: ```js fetch(url) ``` is **not cached by default**. So this: ```js const response = await fetch( "https://api.example.com/products" ) ``` should not be mentally read as: ```text Persistent cache ``` Instead: ```text Fresh data unless you explicitly opt into caching ``` --- > **Interview Highlight** > > **Q: Is `fetch()` cached by default in modern Next.js?** > > No. Modern Next.js does not persistently cache `fetch()` responses by default. Identical fetches are still memoized during a React render, but persistent caching must be explicitly requested. --- # Previous-Model Explicit Caching If you're using the previous model without Cache Components, you can explicitly write: ```js fetch(url, { cache: "force-cache" }) ``` Or: ```js fetch(url, { next: { revalidate: 3600 } }) ``` You'll still see this in production applications. --- # Modern Equivalent With Cache Components, prefer: ```js async function getProducts() { "use cache" cacheLife("hours") return fetchProducts() } ``` or: ```js async function getProducts() { "use cache" cacheLife("hours") return db.product.findMany() } ``` Notice that this also works naturally with database queries. You're caching the **function result**, not only an HTTP `fetch()`. --- # Classic Cache 3: Full Route Cache The previous model also had: ```text Full Route Cache ``` This cached the rendered result of static routes. That included: ```text HTML + React Server Component Payload ``` Conceptually: ```text Build ↓ Render /about ↓ HTML + RSC Payload ↓ Full Route Cache ``` Then visitors could receive the cached route without rendering it again. --- # Full Route Cache and Static Rendering Imagine: ```text /about ``` contains no request-specific work. Next.js could render it ahead of time: ```text Build ↓ Render /about ↓ Store output ↓ Users receive prepared result ``` That's why old caching diagrams linked: ```text Static Rendering ``` closely with: ```text Full Route Cache ``` --- # Full Route Cache Was Not the Data Cache This distinction mattered. ```text Data Cache = Fetched data ``` ```text Full Route Cache = Rendered HTML + RSC output ``` For example: ```text Fetch products ↓ Data Cache ↓ Render page ↓ Full Route Cache ``` Two different layers. --- # Redeploy Behavior in the Previous Model The old Full Route Cache was cleared on deployment. But persistent Data Cache behavior could survive differently depending on platform/configuration. This is another reason the four-cache model became difficult to reason about. You had to ask: ```text Which cache? Where? How long? What invalidates it? What invalidates the cache depending on that cache? ``` At some point the word: ```text cache ``` stopped looking real. 😭 --- # Classic Cache 4: Router Cache The Router Cache lived in browser memory. It stored React Server Component route information for navigation. Conceptually: ```text Browser │ ├── /dashboard ├── /settings └── /profile ``` When navigating: ```text /dashboard ↓ /settings ↓ Back to /dashboard ``` Next.js could reuse route information instead of performing a full document reload. --- # Why the Router Cache Existed It enabled: - Fast back/forward navigation - Partial rendering - Persistent layouts - Prefetching - SPA-like navigation Think: ```text Browser ↓ Already has useful route information ↓ Reuse instead of starting from zero ``` --- # Modern Equivalent Mental Model The client routing system still caches/prefetches useful route data. But modern Next.js increasingly describes this through concepts such as: ```text Prefetching App Shell Partial Prefetching Instant Navigation ``` rather than making the old "four caches" diagram the center of everything. --- # Old Four-Cache Diagram You can visualize the previous model like: ```text SERVER ───────────────────────────────── Request Memoization ↓ Temporary duplicate protection Data Cache ↓ Cached fetch/database data Full Route Cache ↓ HTML + RSC route output CLIENT ───────────────────────────────── Router Cache ↓ RSC route segments / navigation ``` This is still useful historical knowledge. But don't treat it as the only modern architecture. --- # Modern Cache Components Diagram Current Next.js is easier to reason about like this: ```text SERVER COMPONENT ↓ Does this result need caching? │ ├── Yes │ ↓ │ "use cache" │ ↓ │ cacheLife() │ ↓ │ optional cacheTag() │ └── No ↓ Request-time work ↓ ↓ Stream result ``` Then Next.js combines those results into: ```text Static Shell + Cached Content + Streaming Content ``` --- # Revalidation Mental Model Think of caching as two operations. First: ```text SAVE ``` with: ```js "use cache" ``` Then: ```text REFRESH ``` with: ```text cacheLife() revalidateTag() updateTag() revalidatePath() ``` That's the modern model. --- # Example: Blog Cache Data: ```js import { cacheLife, cacheTag } from "next/cache" export async function getPosts() { "use cache" cacheLife("hours") cacheTag("posts") return db.post.findMany() } ``` Now your blog page: ```jsx export default async function BlogPage() { const posts = await getPosts() return ( ) } ``` --- # Admin Updates Post Server Action: ```js "use server" import { updateTag } from "next/cache" export async function editPost( id, data ) { await db.post.update({ where: { id }, data }) updateTag( "posts" ) } ``` Now the user who made the change can see the refreshed cached data immediately. --- # CMS Webhook Example Suppose an external CMS updates your articles. A Route Handler could use: ```js import { revalidateTag } from "next/cache" export async function POST() { revalidateTag( "posts", "max" ) return Response.json({ success: true }) } ``` Now stale content can refresh in the background. --- # `router.refresh()` Is Different Inside a Client Component you may use: ```js router.refresh() ``` from: ```js useRouter() ``` Example: ```jsx "use client" import { useRouter } from "next/navigation" export default function Button() { const router = useRouter() return ( ) } ``` This requests fresh Server Component output for the current route. But it does **not automatically invalidate your server-side cached data**. If the server cache is still stale: ```text router.refresh() ↓ Ask server again ↓ Server returns same stale cache ``` Congratulations. You refreshed your stale data very efficiently. 😭 --- # `refresh()` in Server Actions Modern Next.js also provides: ```js refresh() ``` from: ```js next/cache ``` inside Server Actions. Example: ```js "use server" import { refresh } from "next/cache" export async function updateSomething() { await mutateDatabase() refresh() } ``` This refreshes the client router after the action. But if cached server data itself needs invalidating, use: ```text updateTag revalidateTag revalidatePath ``` as appropriate. --- # Stale Profile Interview Question Imagine: ```text User changes name ``` Database: ```text Asif Imam ✅ ``` Dashboard: ```text Asif ❌ ``` What could be wrong? First ask: ```text Where is the stale value coming from? ``` Possible sources include: - Cached data function - Cached component - Previous-model Data Cache - Previous-model Full Route Cache - Client-side prefetched/router state - A separate client caching library - CDN/application infrastructure Don't just randomly: ```js router.refresh() ``` and hope. --- > **Interview Highlight** > > **Q: A user updates their profile but still sees the old name. How would you fix it in modern Next.js?** > > First identify which cached data represents the profile. Ideally tag that cached data, for example `cacheTag("user:123")`. After the mutation, use `updateTag("user:123")` in the Server Action when the user must immediately see their own update. `revalidatePath("/dashboard")` is another option when path-level invalidation is more appropriate. --- # Example Cached user: ```js import { cacheTag } from "next/cache" export async function getUser( id ) { "use cache" cacheTag( `user:${id}` ) return db.user.findUnique({ where: { id } }) } ``` Mutation: ```js "use server" import { updateTag } from "next/cache" export async function updateUser( id, data ) { await db.user.update({ where: { id }, data }) updateTag( `user:${id}` ) } ``` Now: ```text Database changes ↓ Tagged cache expires ↓ Next read gets fresh user ``` Much more precise. --- # Time-Based Revalidation Sometimes content should refresh automatically. For example: ```text Weather Product catalog News Trending articles ``` You can use: ```js cacheLife() ``` Example: ```js async function getTrendingPosts() { "use cache" cacheLife("minutes") return db.post.findTrending() } ``` You don't need a manual mutation to refresh it. Time handles the refresh policy. --- # On-Demand Revalidation Other data changes only when an event occurs. Example: ```text CMS article ``` Instead of refreshing it every: ```text 5 minutes ``` forever, do: ```text Cache for long time ↓ CMS changes article ↓ Webhook ↓ revalidateTag() ``` Much more efficient. --- # Time-Based vs On-Demand ```text TIME-BASED "Refresh every so often." ``` Use: ```js cacheLife() ``` --- ```text ON-DEMAND "I know exactly when data changed." ``` Use: ```text revalidateTag() updateTag() revalidatePath() ``` --- # Cache Only What Can Safely Be Shared This cannot be emphasized enough. Before caching, ask: ```text Can two different users safely receive this same result? ``` If yes: ```text Caching may be appropriate. ``` If no: ```text Be very careful. ``` --- # Example: Safe Shared Cache ```text Course title Course description Public article Product specification ``` All users can see the same data. Cache away. --- # Example: Dangerous Shared Cache ```text User's unread messages Bank balance Private account details Session data Shopping cart ``` Don't casually put: ```js "use cache" ``` around private request-specific data. The fastest data leak is still a data leak. 💀 --- # Runtime APIs Some information only exists during a real request: ```text cookies() headers() searchParams ``` Example: ```js const cookieStore = await cookies() ``` You can't know that user's cookie at build time. So this work belongs to request-time rendering. Wrap it in Suspense when using Cache Components: ```jsx } > ``` This prevents one dynamic section from forcing the whole route to wait. --- # Advanced: `"use cache: private"` Modern Next.js also has: ```js "use cache: private" ``` for specialized caching that can depend on runtime values such as: ```text cookies headers searchParams ``` This cache is intended for user-specific prefetched behavior rather than shared server caching. It's more advanced. For beginners, start with: ```text Shared reusable data ↓ "use cache" ``` and: ```text Request-specific data ↓ Suspense + request-time rendering ``` Then reach for private caching when you actually understand why you need it. --- # Advanced: `"use cache: remote"` Modern Next.js also supports: ```js "use cache: remote" ``` for cache handlers designed for durable shared caching across runtime instances. This becomes more important with: ```text Serverless deployments Multiple servers Distributed infrastructure ``` where normal in-memory server caching may not survive between requests. Again: ```text Don't optimize for a 200-server distributed architecture before your site has 12 users. 😭 ``` But know the feature exists. --- # Development vs Production Caching behavior can feel different during development. Development prioritizes: ```text Seeing code changes immediately ``` Production prioritizes: ```text Performance Caching Prerendering ``` So when debugging caching: ```bash npm run build npm run start ``` can reveal production behavior more accurately than relying only on: ```bash npm run dev ``` --- # Don't Confuse Caching with Memoization Let's make this crystal clear. ### Memoization ```text Same computation during one render ↓ Reuse result ``` Example: ```js React.cache() ``` or automatic `fetch()` memoization. --- ### Persistent Caching ```text Future renders/requests ↓ Reuse result ``` Example: ```js "use cache" ``` with: ```js cacheLife() ``` They may sound similar. Their lifetimes are completely different. --- # Don't Confuse Caching with Prefetching Another common mistake. ### Caching ```text Store result for reuse ``` ### Prefetching ```text Load something before the user explicitly needs it ``` Example: ```jsx ``` might prefetch route information. Prefetching often populates some form of cache. But: ```text Caching ≠ Prefetching ``` --- # Don't Confuse Revalidation with Refresh ### Revalidation ```text Cached data itself becomes stale/invalid ``` Tools: ```text revalidateTag updateTag revalidatePath ``` ### Refresh ```text Ask for current route UI again ``` Tools: ```text router.refresh() refresh() ``` If the underlying server cache remains stale, refreshing may still return stale information. --- # Common Mistake: Assuming `fetch()` Is Cached by Default Old tutorial: ```js const data = await fetch(url) ``` Instructor: > "Next.js caches that forever." Modern Next.js: > "About that..." 😭 Persistent `fetch()` caching is no longer automatic. Use explicit caching. --- # Common Mistake: Caching Everything Caching every database query isn't optimization. Sometimes data needs to be fresh. Example: ```text Available Seats: 1 ``` You probably don't want: ```text cacheLife("days") ``` unless you're building the most chaotic airline booking system imaginable. 💀 Cache according to freshness requirements. --- # Common Mistake: No Revalidation Strategy This: ```js "use cache" ``` without thinking about when data changes is incomplete architecture. Ask: ```text How does this cache become fresh again? ``` Possible answers: ```text Time Mutation Webhook Manual admin event Never changes ``` Then choose the appropriate API. --- # Common Mistake: Over-Invalidating Suppose: ```text Product 123 changed ``` Don't automatically invalidate: ```text Entire website ``` when you could invalidate: ```text product:123 ``` Granular tags reduce unnecessary work. --- # Common Mistake: Under-Invalidating Opposite problem: ```text Database changed ``` but you never tell the cache. Result: ```text Database New Data ✅ Website Old Data forever ❌ ``` Cache invalidation isn't optional when cached data changes. --- # Common Mistake: Caching User-Specific Data Globally Always think about the cache key. If a cached function depends on a user ID: ```js getUser(id) ``` the ID becomes part of the key. But private runtime values need extra care. Never assume: ```text Server-side = Safe to share ``` Server-side caching can still leak data if designed incorrectly. --- # Common Mistake: Using `router.refresh()` as a Cache Hammer ```js router.refresh() ``` is useful. But it's not: ```text CLEAR ALL CACHES PLEASE ``` It doesn't automatically invalidate every server cache. Understand the stale source first. --- # Modern Caching Decision Tree Start here: ```text Does this data change? │ ├── Never / extremely rarely │ ↓ │ Cache it │ └── Yes ↓ Can users share the same result? │ ├── No │ ↓ │ Request-time / private strategy │ └── Yes ↓ How fresh must it be? │ ├── Seconds/minutes/hours │ ↓ │ "use cache" + cacheLife() │ └── Changes only after events ↓ "use cache" + cacheTag() + on-demand revalidation ``` Then after a mutation: ```text Must user instantly see change? │ ├── Yes │ ↓ │ updateTag() │ └── Slight stale period okay? ↓ revalidateTag(tag, "max") ``` If you don't know the tag: ```text revalidatePath() ``` --- # Quick Modern Reference | Need | Tool | |---|---| | Deduplicate identical `fetch()` during render | Automatic Request Memoization | | Deduplicate DB function during render | React `cache()` | | Cache reusable data | `"use cache"` | | Cache reusable component | `"use cache"` | | Set cache lifetime | `cacheLife()` | | Label cached data | `cacheTag()` | | Background refresh | `revalidateTag(tag, "max")` | | Immediate read-your-own-writes | `updateTag()` | | Invalidate a route | `revalidatePath()` | | Fresh request-time UI | No cache + `` | | Refresh current client route | `router.refresh()` | | Refresh after Server Action | `refresh()` | | Static + dynamic same page | Cache Components + Suspense | | Fast destination navigation | Prefetching / Partial Prefetching | --- # Previous Four-Cache Reference | Mechanism | Location | Purpose | Lifetime | |---|---|---|---| | **Request Memoization** | Server render | Deduplicate identical requests | One render | | **Data Cache** | Server | Reuse cached fetched data | Across requests | | **Full Route Cache** | Server | Cache [HTML](/courses/html) + [RSC](/courses/nextjs) output | Persistent until invalidation/deploy | | **Router Cache** | Browser | Speed up client navigation | Temporary client/session behavior | Remember: > This table describes the **previous caching model**, not the recommended way to mentally model modern Cache Components. --- # Interview Quick Hits > **Q: What were the four classic Next.js caching mechanisms?** > > Request Memoization, Data Cache, Full Route Cache, and Router Cache. --- > **Q: Are these still the main caching model in Next.js 16?** > > Not when using Cache Components. Modern Next.js explicitly caches functions and UI with `"use cache"`, controls lifetime with `cacheLife()`, uses cache tags for revalidation, and combines cached content with request-time streaming through Partial Prerendering. --- > **Q: Is `fetch()` cached by default?** > > No. Modern Next.js does not persistently cache `fetch()` requests by default. Identical requests are still memoized during React rendering. --- > **Q: Request Memoization vs persistent caching?** > > Request Memoization deduplicates identical work within the current rendering pass. `"use cache"` creates reusable cached results across rendering work according to the configured lifetime. --- > **Q: React `cache()` vs `"use cache"`?** > > React `cache()` is useful for deduplicating functions such as database reads within server rendering. `"use cache"` is the Next.js caching directive for reusable data or UI with a configurable lifetime. --- > **Q: What does `cacheLife()` do?** > > It defines the lifetime behavior of content cached with `"use cache"`, including stale, revalidation, and expiration behavior. --- > **Q: What does `cacheTag()` do?** > > It attaches one or more labels to cached content so related cache entries can be invalidated later. --- > **Q: `updateTag()` vs `revalidateTag()`?** > > `updateTag()` immediately expires tagged data and is useful for read-your-own-writes after Server Actions. `revalidateTag(tag, "max")` uses stale-while-revalidate behavior and is useful when a temporary stale result is acceptable. --- > **Q: When should you use `revalidatePath()`?** > > When you need to invalidate cached content associated with a specific route and tag-based invalidation isn't practical. --- > **Q: Does `router.refresh()` clear the server cache?** > > No. It refreshes the current route's Server Component output from the client side, but existing server-side cached data may still be reused unless it is separately revalidated. --- > **Q: What is Partial Prerendering?** > > It allows one route to contain a prerendered static shell with cached content while uncached or request-specific sections stream in at request time. --- # The Mental Model Don't think: ```text "Next.js caches everything." ``` Think: ```text "What work am I willing to reuse?" ``` Then: ```text For how long? ``` Then: ```text Who can safely share it? ``` Then: ```text How does it become fresh again? ``` Your modern caching flow is: ```text EXPENSIVE SHARED WORK ↓ "use cache" ↓ cacheLife() ↓ cacheTag() ↓ REUSE ``` Then when data changes: ```text Mutation ↓ Which behavior do I need? │ ├── Immediate freshness │ ↓ │ updateTag() │ ├── Background refresh │ ↓ │ revalidateTag() │ └── Route invalidation ↓ revalidatePath() ``` Fresh request-specific work becomes: ```text No shared cache ↓ ↓ Request-time rendering ↓ Streaming ``` And Next.js combines everything into: ```text Static Shell + Cached Content + Live Content ``` That's the modern architecture. --- ## Summary Caching in Next.js has evolved significantly. Older App Router applications commonly used the famous four-cache mental model: ```text Request Memoization Data Cache Full Route Cache Router Cache ``` You should understand those concepts because they still exist in older projects and interviews. But modern Next.js 16 with **Cache Components** takes a more explicit approach. The important modern concepts are: - `fetch()` is **not persistently cached by default** - Identical `fetch()` requests are still memoized during React rendering - React `cache()` can deduplicate database or ORM functions within rendering - `"use cache"` explicitly caches reusable [async](/javascript/promises-asynchronous-javascript) functions or components - `cacheLife()` controls cache lifetime - `cacheTag()` labels cached content - `revalidateTag(tag, "max")` performs stale-while-revalidate refreshes - `updateTag()` immediately expires cache after Server Action mutations - `revalidatePath()` invalidates cached content for a route - `router.refresh()` does not automatically invalidate server-side cached data - Request-specific data should usually remain uncached - `` lets fresh data stream without blocking reusable UI - Cache Components enable static, cached, and request-time content inside the same route - Partial Prerendering creates a reusable static shell - Prefetching and Partial Prefetching make client navigation faster - The classic Data Cache and Full Route Cache model is now documented as the **previous caching model** - Modern caching should be intentional rather than assuming everything is cached automatically The biggest rule is: ```text Don't ask: "Is Next.js caching this?" Ask: "Should I cache this, who can share it, how long can it be stale, and how will I invalidate it?" ``` Once you start thinking that way, caching stops feeling like invisible framework wizardry and becomes normal application architecture. And that's how we'll keep approaching caching on **asif.to** — not by memorizing four boxes from an old diagram and hoping `revalidatePath()` fixes everything 😭, but by understanding **what is being reused, for how long, for whom, and what event makes it stale**. Once those four questions are clear, even Next.js caching starts behaving like something built by humans. 🚀