Drupal performance conversations often turn into a pile of cache names: Redis, Memcached, Varnish, CDN, browser cache, render cache, Dynamic Page Cache, BigPipe, purge, cache tags. The confusion usually starts when these tools are treated as competitors.

They are not the same thing. Redis and Memcached help Drupal store internal cache data faster than the database. Varnish caches whole HTTP responses before PHP runs. A CDN moves public assets and cacheable responses closer to visitors around the world. Each layer solves a different problem.

The Short Version

If you remember one rule, make it this: Redis and Memcached are internal Drupal cache backends; Varnish and CDNs are HTTP caches.

Redis In Drupal

Redis is an in-memory data store that Drupal can use as a cache backend. The Drupal Redis module integrates Drupal with Redis and compatible alternatives such as Valkey. Its Drupal.org project page describes cache, lock, flood, queue backends, and cache reporting capabilities.

Redis is usually a good fit when:

• You want to move Drupal cache bins out of the database.
• You need a shared cache backend across multiple web containers.
• You want better lock handling than database locks under traffic.
• Your hosting platform already provides Redis as a managed service.
• You want persistence or more operational visibility than a purely volatile cache.

Typical installation:

composer require 'drupal/redis:^1.11'
drush en redis -y
drush cr

Then configure Redis in settings.php. The exact snippet depends on hosting and client library, but the shape is usually:

$settings['redis.connection']['interface'] = 'PhpRedis';
$settings['redis.connection']['host'] = 'redis';
$settings['redis.connection']['port'] = 6379;

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

Redis does not replace Varnish or a CDN. It still requires Drupal to bootstrap PHP before it can help. Its job is to make Drupal's internal lookups faster and reduce database pressure.

Memcached In Drupal

Memcached is a simple distributed memory cache. The Drupal Memcache module provides integration with Memcached and PECL client libraries, including cache and lock backends. It is battle-tested and still a strong choice when you need a straightforward volatile cache layer.

Memcached is usually a good fit when:

• Your platform already provides Memcached.
• You want a simple shared memory cache for Drupal bins.
• You do not need Redis features such as richer data types or persistence.
• Your operations team already knows how to monitor and scale Memcached.

Typical installation:

composer require 'drupal/memcache:^2.8'
drush en memcache -y
drush cr

A simplified configuration looks like this:

$settings['memcache']['servers'] = ['memcached:11211' => 'default'];
$settings['memcache']['bins'] = ['default' => 'default'];
$settings['cache']['default'] = 'cache.backend.memcache';

Memcached is intentionally simple. It is excellent for cache entries that can disappear at any time and be rebuilt by Drupal. Do not store irreplaceable business data in Memcached.

Redis Vs Memcached: Which One Should You Use?

For most Drupal sites, choose one primary internal cache backend. Running both Redis and Memcached for the same cache bins adds complexity without obvious benefit.

Choose Redis when:

• Your hosting platform recommends it.
• You want cache plus locks, queues, flood backend, or richer operational options.
• You want persistence or Redis-specific observability.

Choose Memcached when:

• Your platform already has a strong Memcached setup.
• You want a simple, fast, volatile cache.
• Your application only needs a basic shared cache backend.

The wrong choice is usually not Redis versus Memcached. The wrong choice is leaving high-traffic Drupal cache bins in the database while trying to fix everything with a CDN.

Varnish In Drupal

Varnish is a reverse proxy cache. It sits in front of Drupal and caches HTTP responses. When Varnish has a cache hit, PHP and the database do not run at all. That is why Varnish can make anonymous traffic dramatically faster.

Varnish is good for:

• Anonymous page caching.
• Public API responses with correct cache headers.
• Reducing origin load during traffic spikes.
• Keeping hot pages fast even when Drupal is busy.

Varnish is risky for:

• Personalized pages.
• Responses that vary by user role, session, cart, or permissions.
• Pages with incorrect cache metadata.
• Sites that clear all cache constantly instead of purging precisely.

Drupal can emit cache metadata such as cache tags, cache contexts, and max-age. With the Purge ecosystem and Varnish purger integrations, Drupal can notify Varnish when content changes so the right cached responses are invalidated.

CDN In Drupal

A CDN is a global edge network. It can cache static assets, images, CSS, JavaScript, anonymous HTML, and some API responses closer to visitors. It may also handle TLS, WAF rules, bot filtering, image optimization, HTTP/2 or HTTP/3, and edge redirects.

A CDN is good for:

• Global latency reduction.
• Static asset delivery.
• Absorbing public traffic spikes.
• Reducing origin bandwidth.
• Security controls at the edge.

A CDN is not a substitute for Drupal cache correctness. If Drupal sends the wrong cache headers, varies incorrectly, or leaks personalized content into public cache, the CDN can make the problem worse and distribute it faster.

How Invalidation Should Work

Caching is easy until content changes. Drupal's cache metadata is designed to help with precise invalidation.

Example: an editor updates node 123.

1. Drupal invalidates cache tags such as node:123.
2. Render cache entries in Redis or Memcached that depend on node:123 become invalid.
3. A purge queue can send tag bans or purge requests to Varnish and the CDN.
4. The next visitor gets fresh content, while unrelated cache entries remain hot.

This is better than running drush cache:rebuild every time content changes. Full cache rebuilds are a development and deployment tool, not a content publishing strategy.

What Drupal Cache Metadata Means

If these are wrong, every cache layer above Drupal becomes harder to trust.

Recommended Layering Pattern

For a medium or large Drupal site, a healthy caching architecture often looks like this:

Visitor
  -> Browser cache
  -> CDN edge
  -> Varnish or platform reverse proxy
  -> Drupal/PHP
  -> Redis or Memcached
  -> Database

Use each layer intentionally:

• CDN caches global public traffic and static assets.
• Varnish caches public HTTP responses close to origin.
• Redis or Memcached handles Drupal internals.
• Drupal cache metadata coordinates freshness.
• The database stores source-of-truth content and configuration.

Common Anti-Patterns

Using CDN Cache To Hide Slow Drupal Internals

A CDN helps anonymous/public traffic, but authenticated traffic, editorial workflows, and cache misses still hit Drupal. If those are slow, add an internal cache backend and profile Drupal.

Running Redis And Memcached Without A Plan

Using both can be valid in special cases, but do not split cache bins randomly. Pick a primary backend unless a hosting platform gives you a clear architecture.

Caching Personalized HTML Publicly

If a response varies by user, session, role, cart, permissions, or private data, be very careful before letting Varnish or CDN cache it. Use cache contexts and private/no-cache headers correctly.

Clearing Everything Too Often

Frequent full cache clears create thundering herds and cold-cache performance drops. Fix invalidation metadata and purge rules instead.

How To Measure Each Layer

Measure separately, because a single “site is fast” number hides where the work is happening.

• CDN: edge hit ratio, origin shield hit ratio, bandwidth saved, geographic latency.
• Varnish: hit/miss/pass ratio, backend fetch time, ban/purge queue behavior.
• Drupal: Dynamic Page Cache hit rate, render cache behavior, slow routes, cache contexts.
• Redis/Memcached: memory usage, evictions, hit ratio, network latency, connection count.
• Database: query count, slow queries, lock waits, cache table pressure.

When a page is slow, ask: did the CDN miss, did Varnish pass, did Drupal bootstrap, did internal cache miss, or did the database do too much work?

Deployment Checklist

• Choose Redis or Memcached as the primary Drupal internal cache backend.
• Move cache bins out of the database for high-traffic sites.
• Enable Drupal page caching and Dynamic Page Cache where appropriate.
• Configure Varnish only after cache headers and contexts are understood.
• Configure CDN caching conservatively, then expand public cache coverage.
• Set up precise purge/invalidation before aggressive TTLs.
• Never cache authenticated or personalized responses publicly without an explicit design.
• Monitor hit rates, evictions, purge latency, and backend response time.

Reference Links

• Redis module on Drupal.org
• Memcache API and Integration module on Drupal.org
• Purge module on Drupal.org
• Varnish Purger module on Drupal.org

Final Takeaway

Redis, Memcached, Varnish, and a CDN are not four names for the same cache. Redis and Memcached make Drupal's internal work faster. Varnish avoids Drupal work by caching full HTTP responses. A CDN moves public content to the edge and reduces global latency.

The strongest Drupal cache architecture has clear responsibility at every layer and precise invalidation across all of them. Start with correct Drupal cache metadata, choose one internal cache backend, add reverse-proxy caching for public responses, then expand to CDN caching with purge rules you can trust.