How do you implement on-demand revalidation from a CMS webhook?

WHAT THIS TESTS: This question tests whether you know the difference between time-based revalidation and on-demand revalidation in Next.js, and whether you understand where cache invalidation logic must live. A senior candidate should demonstrate knowledge of the App Router Route Handler as the webhook receiver, the security implications of exposing a cache purge endpoint, and the distinction between revalidatePath for page cache and revalidateTag for fetch cache. It also surfaces whether you understand that revalidation only marks data as stale and that the actual rebuild happens on the next request.

A GOOD ANSWER COVERS: First, the candidate should describe creating a POST Route Handler at a known path such as app/api/revalidate/route.ts. Second, they must mention validating the incoming webhook with a secret token or signature to prevent denial-of-service or cache poisoning. Third, they should explain calling revalidatePath with the exact page path when the page is statically generated, or calling revalidateTag when the page uses fetch with a cache tag and the data layer needs granular invalidation. Fourth, they should note that the function must be called in a Route Handler or Server Action, not inside a React Server Component during render, because revalidation mutates shared cache state. Fifth, a strong answer mentions that the next request to the page triggers regeneration in the background while serving the stale version briefly, and that on-demand revalidation works with both the Node.js and Edge runtimes depending on setup.

COMMON WRONG ANSWERS: A red flag is suggesting a full CI/CD redeploy for every CMS edit, which defeats the purpose of ISR. Another is proposing to call revalidatePath directly inside a Server Component body, which is illegal because Server Components must be pure and idempotent. Some candidates forget webhook security entirely and leave the endpoint open. Others confuse revalidatePath with router.refresh or assume revalidation happens synchronously during the webhook call rather than on the next visit. Using unstable_cache without supplying tags and then expecting on-demand revalidation to work is also a common trap.

LIKELY FOLLOW-UPS: The interviewer might ask how you would handle a burst of webhooks for thousands of pages, prompting a discussion of debouncing or queueing. They might ask how to verify the webhook signature if the CMS provides one, or how revalidateTag interacts with the fetch cache in the App Router. Another follow-up is asking what happens if the revalidation fails, leading to a conversation about logging, alerting, and fallback behavior.

ONE CONCRETE EXAMPLE: Imagine a blog with a Next.js frontend and a Sanity CMS. When an editor publishes a post, Sanity sends a webhook to your-app.com/api/revalidate. The Route Handler checks the Authorization header against an environment variable, extracts the slug from the JSON body, and calls revalidatePath with the path /blog/ concatenated with the slug. The next visitor to that URL sees the old version for a moment while Next.js regenerates the page in the background. If the post list page at /blog uses a shared fetch tagged with posts, you instead call revalidateTag with the argument posts so both the list and any affected detail pages rebuild without needing individual path enumeration.