Cache invalidation strategies in NextJS - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

What happens when you use stale-while-revalidate in Next.js caching?

In Next.js, when you use the stale-while-revalidate cache control header, what is the expected behavior when a cached page is requested after the stale time has passed?

A The cached page is discarded and a 404 error is returned until the fresh page is generated.

B The request waits until the fresh page is fetched before serving any content to the user.

C The cached page is served immediately while Next.js fetches a fresh version in the background to update the cache.

D The cache is cleared and the user is redirected to the homepage.

💡 Hint

Think about how stale-while-revalidate balances speed and freshness.

The stale-while-revalidate strategy serves the stale cached content immediately to the user, ensuring fast response times. Meanwhile, it triggers a background fetch to update the cache with fresh content for future requests.

❓ component_behavior

intermediate

How does Next.js ISR (Incremental Static Regeneration) handle cache invalidation?

Given a Next.js page using ISR with revalidate: 10, what happens when a user requests the page after 15 seconds since the last generation?

NextJS

export async function getStaticProps() {
  return {
    props: { time: Date.now() },
    revalidate: 10
  };
}

A Next.js serves the cached page immediately and triggers a background regeneration of the page.

B Next.js waits for the page to regenerate before serving it to the user.

C Next.js serves a 404 error because the cache expired.

D Next.js disables caching and regenerates the page on every request.

💡 Hint

ISR allows pages to update without rebuilding the whole site.

ISR serves the existing cached page immediately even if the revalidate time has passed. It then regenerates the page in the background so future requests get fresh content.

📝 Syntax

advanced

Which Next.js cache control header syntax correctly sets a 1-hour max-age with stale-while-revalidate?

Choose the correct way to set the Cache-Control header in Next.js API route to cache for 1 hour and allow stale content while revalidating.

NextJS

export default function handler(req, res) {
  // Set cache control header here
  res.status(200).json({ message: 'Hello' });
}

A res.setHeader('Cache-Control', 'public max-age=3600 stale-while-revalidate=3600');

B res.setHeader('Cache-Control', 'max-age=3600 stale-while-revalidate=3600');

C res.setHeader('Cache-Control', 'public, max-age=3600; stale-while-revalidate=3600');

D res.setHeader('Cache-Control', 'public, max-age=3600, stale-while-revalidate=3600');

💡 Hint

Headers use commas to separate directives.

The correct syntax separates directives with commas. Option D correctly uses commas between public, max-age, and stale-while-revalidate.

🔧 Debug

advanced

Why does this Next.js ISR page never update after deployment?

This Next.js page uses ISR with revalidate: 60. After deployment, the page content never changes even after 5 minutes. What is the most likely cause?

NextJS

export async function getStaticProps() {
  const data = await fetch('https://api.example.com/data').then(res => res.json());
  return {
    props: { data },
    revalidate: 60
  };
}

A The <code>revalidate</code> value must be a string, not a number.

B The API response is cached and does not change, so the page content stays the same.

C ISR only works in development mode, not in production.

D The <code>getStaticProps</code> function must return <code>revalidate</code> inside <code>props</code>.

💡 Hint

Consider what controls the data freshness besides ISR timing.

If the API data does not change or is cached upstream, ISR will regenerate the page but the content remains the same. The issue is likely with the API data source, not ISR itself.

❓ state_output

expert

What is the output of this Next.js API route with cache headers and multiple requests?

Consider this Next.js API route that sets cache headers and returns a timestamp. What will be the output of two requests made 5 seconds apart?

NextJS

let lastGenerated = 0;

export default function handler(req, res) {
  const now = Date.now();
  if (now - lastGenerated > 10000) {
    lastGenerated = now;
  }
  res.setHeader('Cache-Control', 'public, max-age=10');
  res.status(200).json({ timestamp: lastGenerated });
}

A Both requests return the same timestamp because the cache max-age is 10 seconds.

B The second request returns 0 because the cache expired and lastGenerated reset.

C Both requests return different timestamps because the handler updates on every call.

D The first request returns 0, the second returns a new timestamp 5 seconds later.

💡 Hint

Think about how max-age controls browser and CDN caching behavior.

The max-age=10 header tells caches to keep the response for 10 seconds. Since the second request is within 5 seconds, it receives the cached response with the same timestamp.

Practice

1. In Next.js, which method allows you to update static pages after a certain time interval to keep data fresh without rebuilding the entire site?

easy

A. getServerSideProps without caching

B. Manually clearing browser cache

C. Using client-side useEffect to fetch data

D. getStaticProps with revalidate

Solution

1. Step 1: Understand Next.js data fetching methods

   getStaticProps generates static pages at build time, but with revalidate, it can update pages after a set interval.

2. Step 2: Compare with other methods

   getServerSideProps fetches fresh data on every request but does not use caching or revalidation intervals.

3. Final Answer:

   getStaticProps with revalidate -> Option D

4. Quick Check:

   Incremental Static Regeneration = getStaticProps + revalidate [OK]

Hint: Remember: revalidate updates static pages periodically [OK]

Common Mistakes:

• Confusing getServerSideProps with revalidation
• Thinking client-side fetching is cache invalidation
• Assuming manual browser cache clearing affects server cache

2. Which of the following is the correct way to set a revalidation time of 10 seconds in getStaticProps?

easy

A. return { props: {}, revalidate: 10 }

B. return { props: {}, revalidateTime: 10 }

C. return { props: {}, cache: 10 }

D. return { props: {}, refresh: 10 }

Solution

1. Step 1: Recall the correct property name for revalidation

   The Next.js documentation specifies revalidate as the property to set seconds for incremental static regeneration.

2. Step 2: Check the return object structure

   The return object from getStaticProps must include props and optionally revalidate with a number value.

3. Final Answer:

   return { props: {}, revalidate: 10 } -> Option A

4. Quick Check:

   Property name is revalidate [OK]

Hint: Use exact property name 'revalidate' in return object [OK]

Common Mistakes:

• Using incorrect property names like 'revalidateTime' or 'refresh'
• Placing revalidate outside the return object
• Setting revalidate as a string instead of a number

3. Consider this Next.js code snippet:

export async function getStaticProps() {
  return {
    props: { time: Date.now() },
    revalidate: 5
  };
}

What will happen if you visit this page multiple times within 5 seconds?

medium

A. The page will throw an error due to Date.now() in getStaticProps

B. The page will show the same timestamp for all visits within 5 seconds

C. The page will update the timestamp on every visit

D. The page will never update the timestamp

Solution

1. Step 1: Understand revalidate behavior

   The revalidate: 5 means Next.js will regenerate the page at most every 5 seconds.

2. Step 2: Predict output within 5 seconds

   Within 5 seconds, the cached page is served, so the timestamp remains the same for all visits.

3. Final Answer:

   The page will show the same timestamp for all visits within 5 seconds -> Option B

4. Quick Check:

   Revalidate interval caches page for 5 seconds [OK]

Hint: Revalidate caches page until interval expires [OK]

Common Mistakes:

• Assuming timestamp updates on every visit
• Thinking Date.now() causes errors in static props
• Believing revalidate disables caching

4. You wrote this code in Next.js:

export async function getStaticProps() {
  return {
    props: { data: await fetchData() },
    revalidate: '10'
  };
}

Why does this cause a problem?

medium

A. Because revalidate must be a number, not a string

B. Because fetchData cannot be awaited in getStaticProps

C. Because props must be a function, not an object

D. Because revalidate cannot be used with getStaticProps

Solution

1. Step 1: Check the type of revalidate

   The revalidate property expects a number representing seconds, not a string.

2. Step 2: Understand impact of wrong type

   Passing a string causes Next.js to throw a type error or ignore the revalidation, breaking cache invalidation.

3. Final Answer:

   revalidate must be a number, not a string -> Option A

4. Quick Check:

   Revalidate value type = number [OK]

Hint: Use number type for revalidate seconds [OK]

Common Mistakes:

• Passing revalidate as a string
• Thinking async/await is disallowed in getStaticProps
• Confusing props structure requirements

5. You want to always serve fresh data on every request in Next.js without caching. Which method should you use and why?

hard

A. Use getStaticProps without revalidate

B. Use getStaticProps with revalidate: 0

C. Use getServerSideProps because it runs on every request

D. Use client-side fetching only with useEffect

Solution

1. Step 1: Identify method for fresh data every request

   getServerSideProps runs on the server for every page request, ensuring fresh data.

2. Step 2: Compare with static methods

   getStaticProps generates static pages at build time or with revalidation intervals, so it does not guarantee fresh data every request.

3. Final Answer:

   Use getServerSideProps because it runs on every request -> Option C

4. Quick Check:

   Fresh data every request = getServerSideProps [OK]

Hint: Always fresh data? Use getServerSideProps [OK]

Common Mistakes:

• Using revalidate: 0 expecting no caching
• Relying only on client-side fetching for SEO
• Confusing static and server-side methods