Redis Cluster Performance Tuning for High-Traffic Magento Stores

1. When a single Redis instance stops being enough

Redis is typically used in Magento for three distinct purposes: as the backend for the full page cache, as the backend for the configuration cache, and as session storage. All three use cases generate a high volume of read and write operations under heavy traffic, which a single Redis instance handles without trouble at first, since Redis as a single-threaded process per core already reaches very high throughput rates.

The limits of a single instance show up in practice in two places: first, available memory is physically limited, a server with 32 or 64 gigabytes of RAM sets a hard ceiling on how many sessions and cached pages can be held in memory at once. Second, despite asynchronous I/O, Redis remains largely single-threaded for actual command execution internally, which means a single process hits CPU limits at very high request frequency even if the server itself has many cores. Redis Cluster addresses both limits by distributing data and load across multiple independent nodes.

2. Sharding strategy and hash slot distribution

Redis Cluster divides the entire key space into exactly 16384 hash slots, with each individual slot assigned to a single node in the cluster. Which slot a given key belongs to is computed via CRC16 of the key modulo 16384, so distribution tends to be fairly even for random key names, as long as the slots themselves are distributed evenly across the nodes.

With three master nodes, an even distribution would mean each node owns roughly 5461 or 5462 slots. In practice it is worth deliberately assigning keys that logically belong together and are often queried in a single multi-key operation to the same slot using hash tags, for example a curly brace segment in the key name like session:{customer123}:cart, which makes Redis use only the portion inside the curly braces for slot calculation. Without this technique, related multi-key operations would end up spread across multiple nodes and fail with a CROSSSLOT error, because Redis Cluster only allows multi-key commands within the same slot.

3. How it differs from a single instance in terms of scaling limits

The central difference between a single Redis instance and Redis Cluster is that cluster mode enables horizontal rather than vertical scaling. A single instance can only be scaled by adding more memory or a faster CPU on the same server, which eventually runs into physical and economic limits. Redis Cluster, by contrast, lets you simply add more nodes and redistribute hash slots as demand grows, without having to fundamentally rework the application.

That advantage comes at a cost, though: multi-key operations, MULTI/EXEC transactions spanning multiple keys, and Lua scripts that touch several keys at once only work reliably within a single slot, whereas on a single instance they work across the entire key space without restriction. For a Magento setup that uses Redis primarily for the full page cache and sessions, these restrictions are usually manageable, since typical access patterns are already limited to single keys anyway. For more complex use cases with frequent multi-key transactions, it is worth checking carefully before switching to cluster mode.

4. Choosing the right memory eviction policy

Once a Redis node reaches its configured maxmemory limit, an eviction policy has to decide which keys get removed to make room for new data. Choosing the wrong policy either causes Redis to reject write operations with an error once memory is full, or causes important, still-active data to be removed prematurely while rarely used keys stick around in memory unnecessarily long.

For a full page cache, allkeys-lru or allkeys-lfu fits best, because in principle every key should be removable once it has not been requested for a while, and LRU or LFU respectively model exactly that behavior. For sessions, volatile-lru or volatile-ttl is preferable, combined with an explicit TTL on every session key, so Redis preferentially removes keys that would expire soon anyway rather than discarding active sessions prematurely. The noeviction policy should practically never be used in a caching context, because it fully blocks write operations once memory is full, which can lead to visible errors for end users in Magento.

5. Basic Redis Cluster configuration

The configuration below shows the central parameters for a single Redis Cluster node that is part of a larger cluster made up of several masters, each with at least one replica. Besides actually enabling cluster mode, choosing maxmemory and maxmemory-policy to match the node's specific use case matters most.

cluster-node-timeout determines how long a node has to be unreachable before an automatic failover to a replica gets triggered. A value that is too low leads to unnecessary failovers during brief network hiccups, while a value that is too high unnecessarily extends downtime during a genuine node failure.

# redis.conf for a cluster node (full page cache role)
port 6379
cluster-enabled yes
cluster-config-file nodes-6379.conf
cluster-node-timeout 5000

# Memory and eviction for the full page cache role
maxmemory 8gb
maxmemory-policy allkeys-lru

# Persistence deliberately reduced, cache data is disposable
save ""
appendonly no

# Replication for automatic failover
repl-backlog-size 32mb

6. Monitoring cluster hotspots

A commonly underestimated problem in Redis Cluster operations is unevenly distributed load, where a single shard receives noticeably more requests than the others, even though the hash slots themselves are formally distributed evenly. This typically happens when a single, especially frequently requested key, or a small group of keys, for example a bot session with a very high request frequency or a particularly popular full page cache entry, falls into the same slot and disproportionately loads a single node.

To detect such hotspots, the redis-cli --hotkeys command provides a sampling analysis of the most frequently accessed keys on a node, while CLUSTER NODES combined with INFO commandstats per node reveals whether a single node is consistently processing higher CPU load or more commands per second than the rest. In a production setup, it is worth continuously exporting these metrics into Grafana or a comparable monitoring system and triggering an alert whenever the gap between the most and least loaded node crosses a defined threshold.

7. Resharding and expanding the cluster during live operation

A detected hotspot, or simply growing memory demand over time, sooner or later makes resharding necessary, that is redistributing hash slots across a changed number of nodes. Redis Cluster supports this operation during live operation without downtime, through the redis-cli --cluster reshard command, which migrates slots and their associated keys step by step from a source node to a target node while both nodes keep serving read and write requests at the same time.

It matters to deliberately schedule reshard operations outside of traffic peaks and to throttle migration speed via the --cluster-pipeline parameter, because an overly aggressive migration generates additional load itself and, in the worst case, briefly loads an already overloaded hotspot node even more heavily. A newly added node should also initially start out as a replica of an existing, heavily loaded master before taking on its own slots and thus its own master role via reshard, so failover safety is preserved throughout the entire restructuring.

8. Specifics of the Magento integration

Magento's built-in Redis cache backends support Redis Sentinel for high availability, but genuine cluster operation with slot routing requires a cluster-aware client that correctly handles Redis Cluster's MOVED and ASK redirects. Before switching a Magento store to Redis Cluster, it is therefore worth checking whether the PHP Redis extension or client library in use actually supports cluster mode and can be enabled accordingly in the session and cache configuration.

In practice it is advisable to split the full page cache and session storage into separate logical roles within the same cluster, or even into separate clusters entirely, since the two use cases have different eviction policy and persistence requirements. While full page cache data is uncritical to lose, since it simply rebuilds itself, sessions should have at least minimal persistence or replication so that not every failover wipes out all active shopping carts.

9. Eviction policies compared side by side

The table below compares the most common eviction policies to make the choice easier for the specific use case in your own Redis Cluster setup.

10. Summary

11. FAQ: Redis Cluster Tuning: The Essentials at a Glance