Redis Caching for Magento 2: Beyond the Basics

Redis is the standard cache backend for production Magento stores. But most setups barely scratch the surface of what Redis can do — and pay the price in unnecessary cache flushes, slow bulk writes, and missing monitoring.

Here's how to do it right.

The problem with default Magento Redis config

Magento's built-in Redis integration works. But it has significant limitations:

Full cache flushes on every save. By default, Magento flushes the entire cache when a product is saved. On a store with 100k products, that means your entire page cache is cold after every catalog update.

No pipeline batching. Each cache read/write is a separate TCP round-trip to Redis. For operations that set 50+ cache keys at once (like loading a category page), this adds up.

No cluster support. Magento's Redis adapter supports Sentinel (failover) but not Redis Cluster (horizontal scaling). On high-traffic stores, a single Redis instance becomes a bottleneck.

Tag-based cache invalidation

The fix for full cache flushes: tag every cache entry with the entities it depends on.

// Store cache entry with tags
$cache->save($data, 'product_detail_123', ['product_123', 'category_5']);

// Later: flush only entries tagged with product_123
$cache->clean(\Zend_Cache::CLEANING_MODE_MATCHING_TAG, ['product_123']);

When product 123 is updated, only the pages that display that product are invalidated — not your entire cache.

The challenge: Magento's cache adapter doesn't support this natively. You need a custom adapter that maintains a tag-to-key mapping in Redis.

Expected improvement: 90%+ reduction in cache misses after catalog updates.

Pipeline batching

Redis pipelines let you batch multiple commands into a single network round-trip:

// Without pipelining: 50 round-trips
foreach ($keys as $key) {
    $redis->set($key, $data[$key]);
}

// With pipelining: 1 round-trip
$pipe = $redis->pipeline();
foreach ($keys as $key) {
    $pipe->set($key, $data[$key]);
}
$pipe->execute();

For category pages that set 50–100 cache keys, pipelining reduces cache-write time from ~100ms to ~5ms.

Redis Cluster vs. Sentinel

Sentinel handles failover — if your primary Redis instance dies, Sentinel promotes a replica. You get high availability, but you're still limited to one primary node handling all writes.

Redis Cluster shards data across multiple nodes. You can scale writes horizontally by adding nodes. For stores doing millions of cache operations per hour, this matters.

Configuration for Cluster in env.php:

'cache' => [
    'frontend' => [
        'default' => [
            'backend' => 'BetterMagento\RedisTurbo\Cache\Backend\RedisCluster',
            'backend_options' => [
                'cluster_nodes' => [
                    'redis-node-1:6379',
                    'redis-node-2:6379',
                    'redis-node-3:6379',
                ],
            ],
        ],
    ],
],

Session clustering

Storing PHP sessions in Redis works well — but default configuration has a gotcha: if you have multiple app servers, a user's session can be on any node. If that node goes down, they're logged out.

Sticky sessions solve this: route each user consistently to the same app server (and therefore the same Redis primary). Configure this at your load balancer level.

For extra safety, enable session compression:

'session' => [
    'save' => 'redis',
    'redis' => [
        'compression_threshold' => 2048, // compress sessions > 2KB
        'compression_library' => 'lzf',
    ],
],

Compression for large values

Redis stores data in memory. Uncompressed cache values for full pages can be 50–200KB each. At scale, this adds up to gigabytes.

Enable LZ4 or Zstandard compression for values above a threshold:

• LZ4: fastest compression, ~2x ratio — best for latency-sensitive caches
• Zstandard: slower compression, ~3–4x ratio — best for full page cache

Expected improvement: 30–50% reduction in Redis memory usage.

Monitoring

You can't optimize what you don't measure. Key metrics to track:

• Hit rate — aim for >95% on page cache, >80% on default cache
• Memory usage — alert at 80% of maxmemory
• Slow commands — SLOWLOG GET 10 in redis-cli
• Eviction rate — any evictions indicate memory pressure

The BetterMagento Redis Turbo module ships with an admin dashboard showing all of these in real time.

Summary

Issue	Solution	Impact
Full cache flushes	Tag-based invalidation	⭐⭐⭐⭐⭐
Slow bulk writes	Pipeline batching	⭐⭐⭐⭐
Single-node bottleneck	Redis Cluster	⭐⭐⭐
High memory usage	LZ4/Zstandard compression	⭐⭐⭐
No visibility	Admin monitoring dashboard	⭐⭐

Small config changes, massive performance gains.

---

Originally published on magevanta.com