Hotkeys Detection Arrives in Redis

Transcript

Hey there, Redis enthusiasts! Welcome back to another episode of the Redis podcast. I'm your host, and wow, do we have an exciting update to dive into today - January 17th, 2026.

You know that feeling when you're running a Redis instance in production and you just know there are some keys that are absolutely hammering your server, but you can't quite put your finger on which ones? Well, my friends, that problem just got a whole lot easier to solve.

Let's talk about the star of today's show - a massive pull request from minchopaskal that just merged, bringing us hotkeys detection. And when I say massive, I mean it - we're talking about over 2,400 lines of new code across 14 files. This isn't just a small feature addition; this is a game-changer for Redis operations.

So what exactly are hotkeys in this context? Think of them as the keys that are hogging your resources. The new system tracks two crucial metrics: how much CPU time a key is consuming and how much network bandwidth it's eating up. It's like having a performance profiler specifically for your Redis keys.

Here's what I love about this implementation - it's smart. Really smart. Instead of just brute-force tracking everything, which could kill your performance, the team built this on something called a Cuckoo Heavy Keeper structure. It's a probabilistic approach that gives you accurate insights without the overhead. You can sample keys at whatever rate makes sense for your workload.

The API is beautifully straightforward too. You've got four main commands: HOTKEYS START to begin tracking, HOTKEYS GET to see your results, HOTKEYS STOP to pause collection, and HOTKEYS RESET to clean up. The START command gives you tons of flexibility - you can choose which metrics to track, set a duration, adjust sampling rates, and even focus on specific slots.

What really impressed me is how thoughtful they were about performance. In the worst-case scenario, tracking every single key, you're looking at maybe a 15% performance hit. But with smart sampling? The overhead becomes negligible. That's the kind of engineering that makes my developer heart happy.

This feature also plays nicely with the INFO command, adding a new "hotkeys" section that shows you tracking status, memory usage, and CPU time spent on tracking itself. It's that kind of observability that separates good tools from great ones.

I have to give a shout-out to the collaboration here too. This wasn't just minchopaskal working in isolation - we had contributions from Ozan Tezcan, Slavomir Kaslev, and debing.sun. That's the kind of teamwork that produces robust, well-tested features.

The pull request went through proper review too - one change request and 29 comments of discussion. That's exactly the kind of thorough process that gives me confidence in the quality of what's landing in Redis.

Now, for today's focus - if you're running Redis in production, this is definitely something to keep an eye on. Start thinking about how hotkeys detection could help you optimize your workloads. Maybe you'll discover that one key pattern that's been quietly eating up resources. Maybe you'll validate that your caching strategy is working as expected. Either way, you'll have data instead of guesswork.

If you're contributing to Redis or thinking about it, take a look at this pull request. It's a masterclass in how to introduce a significant new feature - comprehensive documentation, thoughtful API design, performance consideration, and solid testing.

That's a wrap for today's episode! The Redis ecosystem keeps getting more powerful, and I couldn't be more excited about where we're heading. Keep coding, keep optimizing, and I'll catch you on the next one. Until then, may your hotkeys be few and your cache hits be many!