A hot key in Valkey is a single key that receives a disproportionately large volume of read requests, overwhelming the Valkey instance responsible for it.
Let’s see this in action. Imagine a Valkey cluster with a few nodes. A popular product page might have its product details stored under a key like product:12345. If this product is suddenly trending, every request to view it hits the exact same key on the exact same Valkey node.
Client -> Load Balancer -> Valkey Node A (responsible for `product:12345`)
Client -> Load Balancer -> Valkey Node A (responsible for `product:12345`)
Client -> Load Balancer -> Valkey Node A (responsible for `product:12345`)
This single node, Valkey Node A, becomes the bottleneck. CPU spikes, memory might get strained from the sheer volume of command processing, and latency for all clients increases, even those requesting unrelated keys that happen to be on Node A.
The core problem this solves is uneven resource utilization. Valkey, especially in a cluster, is designed for distribution, but a hot key creates a localized concentration of work.
Internally, Valkey shards keys across nodes. This distribution is based on a hash of the key. However, if a single key is the target of 90% of reads, its shard becomes saturated regardless of how empty other shards are.
The primary levers you control are your application’s key naming strategy and how you leverage Valkey’s clustering features.
One common approach is to "shatter" the hot key. Instead of product:12345, you might break it down. For example, if the product data has distinct components like name, price, description, you could store them as:
product:12345:nameproduct:12345:priceproduct:12345:description
This requires more requests from the application to fetch the full product details, but each request now targets a different key. These new keys will likely be distributed across different Valkey nodes in the cluster, effectively distributing the read load. Your application logic would then reassemble the data.
Another strategy is to use a Valkey cluster’s hash slot mechanism more intelligently, potentially using a "hash tag." A hash tag is a substring within a key enclosed in curly braces {}. Valkey uses only the part within the braces to determine the hash slot. So, if product:12345 is a hot key, you could rename it to product:{12345}:details. All variations of this product’s data would then use the same hash tag, ensuring they land on the same node. This is useful if you need related data to be co-located, but might not solve the hot key problem directly if the entire product:12345 entity is hot.
A more advanced technique is to introduce a read replica layer. While Valkey itself doesn’t have built-in read replicas in the traditional sense for a standalone instance, in a cluster, you can leverage the fact that commands can be routed to any node. You could implement application-level logic or use a proxy that directs read requests for known hot keys to a dedicated set of Valkey nodes that are not the primary masters for those keys. This effectively creates a read-only cache layer.
Consider the GET command. When a client sends GET product:12345, Valkey’s cluster logic determines which node is responsible for the hash slot of product:12345. If this key is hot, that node’s CPU and network I/O will be saturated. By shattering the key into GET product:12345:name, GET product:12345:price, etc., and assuming these keys hash to different slots, the load is spread. The client application then performs multiple GET requests, each potentially hitting a different Valkey node. This distributes the request processing across multiple CPU cores and network interfaces within the Valkey cluster.
Even with sharding, a single key can dominate. The key user:session:abcdef12345 might be requested millions of times per second if it’s an active user’s session ID. If all requests for this specific session ID hash to the same slot, the node owning that slot will be overwhelmed. The solution isn’t to change the hashing algorithm, but to change the key itself or how it’s accessed.
The most impactful mitigation often involves introducing a layer of indirection or transforming the data structure. For instance, if you have a frequently accessed list, instead of GET my_hot_list, you might store individual items with unique IDs and use a separate Valkey set or sorted set to map the "hot list" concept to these individual item keys.
The next step after mitigating hot keys is often dealing with write contention on related keys.