Drupal + GraphQL: Edge Caching Strategies That Actually Work

Headless Drupal is compelling on paper — a battle-tested CMS backend powering any front-end framework you choose. In practice, the cache invalidation story between Drupal and an edge CDN can get messy fast. Here's what I've learned shipping three large-scale decoupled sites.

Why Edge Caching Matters for GraphQL

Traditional REST endpoints map cleanly to URL-based cache keys. GraphQL collapses all queries to a single endpoint, which breaks naive CDN caching. You need tag-based or surrogate-key caching to invalidate selectively when content changes.

// Next.js 15 fetch with Drupal surrogate keys
const res = await fetch(`${DRUPAL_GRAPHQL_URL}`, {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ query, variables }),
  next: { tags: ["drupal-content", `node:${nid}`] },
  cache: "force-cache",
});

// Revalidate on Drupal webhook
await revalidateTag(`node:${nid}`);

The Surrogate Key Pattern

Drupal's HTTP Cache module can emit Surrogate-Key or Cache-Tags headers listing every entity involved in a response. By forwarding these to your CDN or Next.js cache, you can invalidate only the pages that include the updated node — nothing else.

• check_circleEnable the `http_cache_control` module in Drupal
• check_circleMap Drupal cache tags → Next.js revalidateTags in a webhook handler
• check_circleStore tag → URL mappings in Redis for bulk invalidations
• check_circleAdd a circuit breaker to avoid stampedes on high-traffic invalidations

Results

After applying these patterns on Spectrum Cruise, median TTFB dropped from 340 ms to 140 ms on cache-hit paths, and editorial deploys stopped triggering full-site invalidations. The same pattern has since been applied to two more enterprise clients with consistent results.