Topic

Understand caching

Definition

Caching stores a reusable response or rendered result so later equivalent work can avoid repeating a request or computation.

In simpler words

A cache is a speed tool with freshness rules, not another source of truth.

Next server caches and TanStack Query’s browser cache solve different problems and must not be confused.

Open official example (opens in new tab)

After this you can

Name the cache layer holding a value
Choose conservative freshness rules
Build cache keys that identify a result

Separate server and browser caches

Next caching concerns server-rendered work and its fetch or route output policies. TanStack Query caches representations that a browser client has requested from Nest.

A cache key is a statement of identity. If a ticket list changes when status changes, the status belongs in the Query key; otherwise one filter can show another filter’s cached result.

A complete client cache key

useQuery({
  queryKey: ['tickets', { status: 'open', page: 1 }],
  queryFn: () => ticketsApi.list({ status: 'open', page: 1 }),
});

Every result-affecting input appears in both the key and request.

Mistake: one key for different filters

// Wrong — "closed" can reuse an "open" list
queryKey: ['tickets']

// Right
queryKey: ['tickets', { status, page }]

A cache cannot distinguish results you do not identify.

Choose freshness deliberately

Definition

Freshness policy decides when cached work may be reused and when new work is required.

In simpler words

Shorter freshness improves recency; longer freshness reduces repeat work.

Begin conservatively for product data whose correctness matters more than avoiding a request.

Measure a real problem before adding cache complexity or a second client-side copy of server data.

Live playground

Caching playground

Change a filter and inspect which part of the key must change.

Query cache: stale

Next revalidatePath/tag is for Next server caches — not Nest auth.

Keep in mind

Include all result-changing inputs in cache keys.
Name whether a value is cached by Next or Query before invalidating it.
Do not cache authorization decisions in the UI as a security control.

Test

Check your understanding

At least 10 questions — mix of concept, syntax, practical, and logic. Score ≥80% (enforced by the API) to save progress.

Checking your session…

15 questions · concept 5 · syntax 3 · practical 4 · logic 3

1. What can Next cache?

Concept

Only fetch results made with the native fetch APIFull routes, fetch results, and rendered output depending on configurationOnly fully static pages with no dynamic segmentsOnly React component state between navigations

2. Static vs dynamic rendering?

Syntax

Static renders per request; dynamic is prerendered at buildStatic can be cached/prerendered; dynamic renders per request/userStatic uses Server Components; dynamic uses Client ComponentsStatic caches in the browser; dynamic caches at the CDN

3. Why cache?

Practical

To guarantee every user always sees the freshest dataSpeed and lower backend load for unchanged dataTo move rendering from the server into the browserTo store per-user session data between requests

4. User-specific pages?

Logic

Static, but keyed by the user’s ID in the route cacheStatic, since reading cookies makes each render uniqueDynamic only for the first request, then cached per sessionUsually dynamic — don’t serve one user’s HTML to another from shared cache carelessly

5. fetch cache option awareness?

Concept

The cache option only works on POST requestsfetch ignores cache options unless you also set no-storecache/revalidate options affect whether results are reusedOnly revalidate matters; the cache option is deprecated

6. Route segment config?

Practical

A cacheConfig object exported from next.configexport const dynamic / revalidate style controlsDecorators like @Dynamic() on the page componentA <Cache> wrapper component around the page

7. CDN caching?

Syntax

The CDN caches only static assets, never rendered HTMLCDN caching replaces Next’s own data cache entirelyThe CDN caches each user’s private HTML by cookieDeployment platforms may cache responses at the edge

8. Cache stampede risk?

Logic

Many clients refetch together — design revalidate/tags thoughtfullyA single stale entry corrupts every other cache keyThe cache grows unbounded until it exhausts disk spaceTwo revalidate values on one route cancel each other out

9. Debugging stale UI?

Concept

Assume a hydration mismatch and add "use client"Bump the component key to force React to remountCheck caching/revalidation path before blaming React state onlyClear localStorage since that’s where Next stores the cache

10. Which statement is true?

Practical

Caching is powerful but must respect auth and freshness rulesCaching should include the user’s cookies in the shared entryDisabling all caching is the safest default for every appCached pages never need revalidation once they’re built

11. By default, can Next cache this fetch result?

Conceptintermediate

const res = await fetch(url); // default options

No — Next can never cache a fetch resultYes — depending on configuration, fetch results can be cachedNo — only getStaticProps results are cachedYes, but only the response status, not the body

12. What does this segment config do?

Syntaxadvanced

export const dynamic = 'force-dynamic';

Forces dynamic rendering per request, opting out of static cachingForces the route to prerender statically at build timeEnables dynamic imports for the route’s componentsMakes fetch calls dynamic but keeps the page static

13. This user-specific dashboard is statically cached. What is the risk?

Practicaladvanced

// dashboard shows the logged-in user's private data, statically cached

The dashboard would fail to build because it reads cookiesStatic caching strips the user’s data, showing an empty pageEach request would rebuild the whole app to stay freshOne user’s cached HTML could be served to another; keep it dynamic

14. What does revalidate: 60 mean here?

Logicintermediate

fetch(url, { next: { revalidate: 60 } });

Serve stale data for 60 seconds, then delete it from the cacheCache the result and refresh it at most every 60 secondsRefresh the data on every request once 60 seconds passKeep the data cached until 60 requests have been served

15. UI shows old data after an update. What should you check first?

Conceptintermediate

// UI shows old data after a successful update

The caching/revalidation path — the data may be served from cacheWhether the component forgot to call useState after the writeWhether the browser’s HTTP cache needs a hard refreshWhether the database write silently rolled back

Checking your session…