Invalidating specific cache tags programmaticallyfor Drupal 8 , 9 , 10 , and 11

Every Drupal developer eventually reaches for drush cr as their default answer to "the site is doing something weird." It works, but it's the equivalent of shutting down the entire restaurant kitchen and relighting every burner because one dish came out wrong. This lesson is about the more surgical tools available once you actually know what needs clearing.

What you'll learn in this lesson

• The difference between a full cache rebuild and a targeted invalidation
• How to clear one specific cache bin instead of everything
• Why invalidateTags() is almost always the better tool once you know the dependency

The blunt instrument: a full rebuild

drush cache:rebuild
# or the shorthand:
drush cr

This clears every cache bin on the site and rebuilds Drupal's container, plugin discovery, routing table, and more. It's the right tool after deploying new code (a new hook implementation, a changed service definition, a new route) — situations where Drupal's own discovery caches, not just content caches, need to catch up. It is not the right tool for "a piece of content looks stale," because it throws away every other visitor's warm cache along with the one thing that actually changed.

More targeted: clearing a specific bin

\Drupal::cache('render')->deleteAll();
// Or, via the injected cache.render service in a class:
$this->cacheRenderBin->deleteAll();

Drupal organizes cached data into named bins — render, data, discovery, bootstrap, and others — each holding a different category of cached item. Clearing one bin is faster and less disruptive than a full rebuild, but it's still coarser than invalidating by tag: it throws away every render-cached item site-wide, not just the ones that actually depend on what changed.

The precise tool: invalidate by tag

use Drupal\Core\Cache\Cache;

Cache::invalidateTags(['node:42']);

If you already know exactly what changed and your content was properly tagged (see the earlier lesson on cache tags), this is the correct tool almost every time — it touches only the cached items that actually depended on node 42, across every cache bin at once, leaving everything else warm.

Quick check: after deploying a new module with a new hook implementation, your hook doesn't seem to be firing. Would Cache::invalidateTags() fix this? (No — a missing hook implementation is a discovery-cache problem, not a content-cache problem. You need drush cr to rebuild the module/hook discovery caches; tags only invalidate content-dependent caches, not Drupal's own internal bookkeeping.)

Key takeaways

• A full drush cr rebuilds discovery caches too (hooks, routes, plugins) — necessary after code changes, overkill for content changes.
• Clearing a specific bin (\Drupal::cache('render')->deleteAll()) is more targeted than a full rebuild but still coarser than tag-based invalidation.
• Cache::invalidateTags() is the most precise tool and should be your default for anything driven by normal content or config changes.

Coming up next

You've now covered the core cache-metadata toolkit. Next, we look at BigPipe — a technique that doesn't just cache content faster, but changes how the page is delivered so slow, uncacheable pieces stop blocking the fast ones.