Configuring Redis for high-performance cachingfor Drupal 8 , 9 , 10 , and 11

Redis and Memcache solve the same core problem — a shared, in-memory cache visible to every web server in your cluster — but Redis adds two things Memcache deliberately leaves out: optional persistence to disk, and richer data structures beyond simple key/value pairs. For Drupal's purposes, the practical difference that matters most is persistence: a Redis instance configured to snapshot to disk can survive a restart with its cached data intact, where Memcache always comes back completely empty.

What you'll learn in this lesson

• How to wire the Redis contrib module into Drupal's cache backend system
• What Redis persistence actually buys you for a cache-only workload — and why it's often not worth turning on
• Why Redis is also commonly used for Drupal's lock and flood-control systems, not just caching

Installing and configuring the Redis backend

composer require drupal/redis
drush en redis -y

The Redis module needs its client class loaded before Drupal's container is built, which means (unlike Memcache) it typically requires a small addition near the top of settings.php in addition to the usual cache-backend switch:

if (extension_loaded('redis') || class_exists('\Predis\Client')) {
  $settings['redis.connection']['interface'] = 'PhpRedis';
  $settings['redis.connection']['host'] = '127.0.0.1';
  $settings['cache']['default'] = 'cache.backend.redis';
  $settings['container_yamls'][] = 'modules/contrib/redis/example.services.yml';
}

That container_yamls line is the detail people most often miss: Redis needs its own service definitions registered with the container (for the lock backend and flood backend, covered below), and those live in a services file the module ships but doesn't auto-load — you have to explicitly tell Drupal to include it.

Persistence: available, but rarely worth enabling for cache

Redis beyond caching: locks and flood control

Once the Redis module and its container_yamls service definitions are loaded, you can also point Drupal's lock backend (used to prevent race conditions, like two cron runs starting simultaneously) and flood backend (used for rate-limiting things like failed login attempts) at Redis instead of the database:

services:
  lock:
    class: Drupal\redis\Lock\RedisLockBackend
  flood:
    class: Drupal\redis\Flood\FloodBackend

This matters specifically because locks and flood control are exactly the kind of high-frequency, low-latency operations where a database round-trip is comparatively expensive — moving them to an in-memory store that's already running for caching is close to free.

Quick check: you're running Redis purely as a cache backend, with nothing else depending on it. Should you enable disk persistence "just to be safe"? (Answer: generally no — persistence adds write overhead to every cache operation, and since Drupal always treats a cache miss as safe to recompute, there's nothing to protect. Persistence earns its cost when Redis also backs something non-disposable, like a queue or session store.)

Key takeaways

• Redis and Memcache solve the same shared-cache problem; Redis additionally offers optional persistence and richer data structures.
• The Redis module needs both the cache-backend switch and a container_yamls entry to register its full service set — missing the latter is a common setup mistake.
• Persistence is rarely worth enabling for a cache-only workload, since Drupal's cache contract already assumes any value can vanish and be recomputed.
• The same Redis instance can also back Drupal's lock and flood-control systems, which benefit from low-latency in-memory access even more than the cache does.

Coming up next

With a backend chosen and configured, the next lesson covers tuning it — things like compression and connection settings that squeeze more throughput out of whichever backend you've picked.