Gatsby ISR and Plugin Cache Invalidation: Choosing a Zero‑Downtime Update Strategy

Question

Ensuring data freshness with Gatsby ISR during zero‑downtime migration
Goal: update content in a small Gatsby site using Incremental Static Generation (ISR) so that only changed pages regenerate while the site remains served.
Constraint: ISR regenerates HTML only; data source plugins continue to serve cached data unless they implement incremental fetching, and the documentation does not define a standard method for plugin‑level cache invalidation.
Uncertainty: developers must decide whether to accept occasional stale data, trigger full rebuilds, or implement custom webhook or plugin hooks to refresh data.

What strategies exist for plugin‑level cache invalidation that work with ISR without causing full rebuilds?
How can a custom webhook be configured to signal plugins to purge their caches while keeping ISR active?
Are there any plugin‑specific options or conventions that safely enable incremental data fetching alongside ISR?

Tasadduq Burney · Answer

Answer: Plugin‑level cache invalidation strategies compatible with Gatsby ISR
The goal is to keep ISR serving existing HTML while ensuring that source‑plugin data stays fresh after a content change, without triggering a full site rebuild.
Confirmed facts

ISR only regenerates the HTML of pages whose revalidate interval has elapsed; it does not automatically refresh data cached inside source plugins.
If a plugin’s internal cache is not cleared, stale data can persist until the next revalidate interval or a full rebuild.
Some source plugins (e.g., gatsby-source-contentful in preview/webhook mode) already support incremental fetching when a short revalidate is set.

Likely explanation / recommended steps

Expose a plugin‑specific purge function – If the plugin exports a function like clearCache(), configure your content‑change webhook to call that function (via a small Node script or serverless endpoint). ISR will continue serving the previous HTML; only the plugin’s internal store is refreshed, so the next ISR regeneration picks up the new data.
Use a plugin that supports incremental fetching – Choose a source plugin that honors options such as pageLimit, preview, or webhook mode. Set a short revalidate (e.g., 30 seconds) in gatsby-config.js. When ISR rebuilds a page, the plugin will refetch only the changed nodes, keeping its cache up‑to‑date without a full rebuild.
Trigger an incremental Gatsby build via webhook – Configure the webhook to run gatsby build --incremental --only‑changed. In the same webhook payload, invoke the plugin’s purge hook (if available). This rebuilds only the affected pages and clears the plugin cache, preserving zero‑downtime serving of unchanged pages.

Missing diagnostic detail
Does your source plugin expose a public purge function (e.g., clearCache()) or support incremental fetching via plugin options? Knowing this determines whether you can rely on Strategy 1 or need to adopt Strategy 2.

Gatsby ISR and Plugin Cache Invalidation: Choosing a Zero‑Downtime Update Strategy

Ensuring data freshness with Gatsby ISR during zero‑downtime migration

1 answer

Answer: Plugin‑level cache invalidation strategies compatible with Gatsby ISR

Confirmed facts

Likely explanation / recommended steps

Missing diagnostic detail

Your perspective belongs here.

0 question comments