🧠 New cache.memory Bin Replaces cache.static — What’s New in Drupal 11.3

Introduced in Drupal 11.3.0, a new standardized in-memory cache bin called cache.memory replaces the old cache.static bin. This change modernizes how Drupal handles in-memory caching, improves performance, and clarifies the intended use of memory-based caches.

🚀 Overview

The new cache.memory bin is powered by the backend
Drupal\Core\Cache\MemoryCache\MemoryCache.

It provides a lightweight and efficient in-memory cache that:

• Stores data only for the duration of a single request.
• Does not serialize or deserialize cached data (faster access).
• Supports in-request cache tag invalidations — when a tag is invalidated during the same request, related cached items are automatically cleared.

However, invalidations that occur in other requests do not affect this cache, since it is purely in-memory.

⚠️ Deprecated Components

The following are now deprecated:

💻 Why This Matters

Previously, cache.static used the backend Drupal\Core\Cache\MemoryBackend, which serialized and deserialized all stored data to prevent reference modification. This made it safe but slower and primarily suited for testing (Unit or Kernel tests).

With cache.memory, developers now have a fast, standardized, and tag-aware in-memory cache for runtime operations.

🧩 Example: Migrating Your Code

Before (Deprecated)

use Drupal\Core\Cache\MemoryCache\MemoryCacheInterface;

class MyService {
  public function __construct(MemoryCacheInterface $cache) {
    $this->cache = $cache;
  }

  public function loadSomething($id) {
    if ($cache = $this->cache->get($id)) {
      return $cache->data;
    }
    $data = $this->loadFromExternalSource($id);
    $this->cache->set($id, $data);
    return $data;
  }
}

After (New Recommended Approach)

use Drupal\Core\Cache\CacheBackendInterface;
use Symfony\Component\DependencyInjection\Attribute\Autowire;

class MyService {
  public function __construct(
    #[Autowire('cache.memory')]
    CacheBackendInterface $cache
  ) {
    $this->cache = $cache;
  }

  public function loadSomething($id) {
    $cid = 'my_module:' . $id; // Always prefix your cache IDs!
    if ($cache = $this->cache->get($cid)) {
      return $cache->data;
    }

    $data = $this->loadFromExternalSource($id);
    $this->cache->set($cid, $data, CacheBackendInterface::CACHE_PERMANENT, ['custom_tag']);
    return $data;
  }
}

💡 Tip: As with other shared cache bins, always prefix your cache IDs with your module or class name to avoid conflicts.

🧠 In-Request Cache Tag Invalidations

The cache.memory bin supports cache tag invalidations within the same request.
This means if you call Cache::invalidateTags(['custom_tag']) later in the same request, any data cached under those tags will be automatically invalidated.

However, invalidations happening in other requests (e.g., triggered by cron or admin actions) won’t affect data stored in cache.memory.

🛠 Updating Your Configuration

If your configuration or settings.php contains:

$settings['cache']['default'] = 'cache.backend.memory';

It must now be updated to:

$settings['cache']['default'] = 'cache.backend.memory.memory';

✅ When to Use cache.memory

Good use cases:

• Caching expensive computations during a single request.
• Temporary data sharing between services in the same request.
• Replacing static variables for short-lived caching.

Avoid using it for:

• Persistent caching across multiple requests.
• Storing entities (use entity.memory_cache for that).

🧾 Summary

🧰 Conclusion

The new cache.memory bin brings clarity, speed, and consistency to Drupal’s caching system.
It’s designed for developers who need a fast, in-request cache that doesn’t persist between requests but supports tag-based invalidation within the same execution cycle.

By migrating from cache.static to cache.memory, you ensure your modules are forward-compatible and aligned with modern Drupal best practices.