Redis Hot Keys: Fixing Latency Spikes at Scale

If you searched for "redis hot key problem" or "why does my redis latency spike under load," here's the short answer up front: a hot key is a single key receiving a disproportionate share of traffic, and it can pin the CPU of one shard while the rest of your cluster sits idle. You can't eliminate hot keys by adding more nodes — you fix them by detecting the pattern, splitting or caching the key client-side, and coalescing duplicate requests so one popular row doesn't become a single point of failure for your whole SaaS.

Hot keys are one of the most misdiagnosed production incidents in Redis-backed systems. The metrics look like a capacity problem — CPU, memory, and connection counts all look fine on average — but p99 latency climbs, timeouts appear in one region, and nobody can explain why scaling the cluster horizontally didn't help. This is the last piece in our Redis-at-scale series, following our deep dives into RDB vs AOF persistence trade-offs and maxmemory eviction policy. Here we cover the failure mode neither of those fixes: uneven key-level load.

What is a hot key, and why does it break the "just add nodes" fix?

Redis Cluster and most managed Redis offerings (ElastiCache, MemoryDB, Redis Cloud) shard data across nodes using a hash slot. In theory this spreads load evenly. In practice, real-world access patterns are almost never uniform — they follow a power law. A viral product listing, a trending hashtag, a single tenant's dashboard config, a global rate-limit counter, or a feature flag checked on every request can all funnel a huge share of traffic onto one key, and therefore one shard.

Because Redis is single-threaded for command execution (even Redis 7+'s I/O threading doesn't parallelize command processing on one key), every GET, INCR, or HGETALL against that key serializes behind the others. Adding shards doesn't help, because the hot key still lives on exactly one shard — you've just added capacity nothing was using. This is the core reason "scale out" and "fix the hot key" are two separate problems.

Detecting hot keys before they page you

You need visibility at the key level, not just the instance level. In our client engagements, we layer three detection methods so no single blind spot hides an emerging hot key:

• redis-cli --hotkeys — samples keyspace access via LFU counters (requires maxmemory-policy set to an *-lfu variant, or at minimum allkeys-lfu/volatile-lfu to get meaningful frequency data)
• OBJECT FREQ <key> — check a suspected key's approximate access frequency directly, cheap enough to run in a health-check script
• Shard-level dashboards in Prometheus + redis_exporter or CloudWatch (for ElastiCache) — alert on CPU or command-rate skew of more than ~30% between shards, which is the earliest reliable signal
• Client-side sampling — log a random 0.1% of cache keys accessed per request at the application layer; this catches hot keys before they saturate a shard, since server-side counters only show you the damage after the fact

Avoid running MONITOR in production to hunt for hot keys — it captures every command and can itself become a bottleneck on a busy instance. Treat it as a last-resort, time-boxed diagnostic tool, never a standing dashboard.

The fix: architecture patterns, not bigger instances

1. Split the key client-side

For counters and aggregates (view counts, rate limiters, leaderboard scores), shard the key itself: write to key:{id}:{0-9} chosen by a hash of the client or request, then sum the shards on read. This turns one hot key into ten warm ones distributed across the cluster. It's the single highest-leverage fix for INCR-heavy hot keys and requires no infrastructure change.

2. Add a local (L1) cache in front of Redis

If the same handful of keys — a feature-flag set, a pricing table, a tenant's config — are read on nearly every request, cache them in-process (an LRU map in your app, or a library like node-lru-cache) with a short TTL of 1-5 seconds. This is the caching-strategy lever most teams skip: at high throughput, shaving even a few hundred milliseconds of local freshness off a handful of hot reads removes 90%+ of the Redis calls for those keys entirely, because most SaaS config and flag data doesn't need per-request freshness.

3. Coalesce concurrent requests (single-flight)

When a hot key expires, a cache stampede sends dozens or thousands of concurrent requests to the database to regenerate the same value simultaneously. Wrap cache misses in a single-flight pattern (one in-flight regeneration per key, other callers await the same promise) or take a short SET NX lock before recomputing. Combine this with TTL jitter — add ±10-20% random variance to expirations — so keys set at the same time don't all expire in the same millisecond.

4. Fan hot reads out to replicas

For read-heavy hot keys where slight staleness is acceptable, route reads to replicas (READONLY mode in Cluster, or explicit replica endpoints) instead of the primary. This doesn't fix an imbalanced shard, but it multiplies the read capacity available for that specific key across N replicas, buying time while you implement a structural fix.

A realistic scenario: a pricing page that took down checkout

A common pattern we see in SaaS and e-commerce platforms: a single Redis key caches a global pricing or promotion config, read on every page load and every checkout call. Traffic is fine at normal volume. Then a promotion goes out in an email blast or gets picked up by a deal aggregator, request volume triples in minutes, and that one key's shard maxes out its CPU while every other shard in the cluster sits under 20% load. Checkout latency climbs, timeouts cascade into the payment provider's retry logic, and the team scales the Redis cluster horizontally — which does nothing, because the new nodes never see a single request for that key.

The actual fix took under a day: move the pricing config to an in-process cache refreshed every 2 seconds via Redis pub/sub invalidation, so 99% of reads never hit Redis at all, and the remaining refresh traffic is naturally staggered. This is the kind of architectural review we run for clients before a launch or campaign that we expect to spike traffic — cheaper to find in a load test than in a postmortem.

How Fepiq approaches Redis architecture for clients

We build and operate Redis as caching, session, and queue infrastructure for SaaS platforms running on Laravel, Node.js, and TypeScript stacks, deployed on AWS (ElastiCache and self-managed clusters alike). Hot-key and eviction-policy reviews are a standard part of our pre-launch and pre-scale-event checklists — the same checklist we use before a client's product launch, funding announcement, or seasonal traffic spike — so the failure mode above gets caught in staging, not in your incident channel.