02 / 03

How do you handle the "hot key" problem in Redis Cluster?

Difficulty: 7/10
hot keys, sharding, load balancing

A hot key concentrates traffic on one shard.

Solutions:
  1. 1

    Local in-process caching (LRU cache in the app layer) with short TTL

  2. 2

    Key hashing with suffix (product:1:{shard_0}, product:1:{shard_1}) to spread across slots — but loses atomic ops

  3. 3

    Read replicas with READONLY mode in Cluster for read-heavy hot keys

  4. 4

    Proxy-level fan-out (Twemproxy, Envoy)

Scenario Questions

0-2 years experience

  1. 1If you notice a single key getting most of the read traffic in a Redis Cluster, what steps would you take to mitigate the hot key issue?
  2. 2How would you configure Redis Cluster to spread the load of a hot key across multiple nodes?
  3. 3What impact on latency would you expect if a hot key resides on a single shard while other shards are idle?

2-5 years experience

  1. 1Your service is experiencing spikes in latency because a leaderboard key is a hot key in Redis Cluster. Walk me through how you would diagnose and resolve it, considering trade‑offs.
  2. 2Explain why moving a hot key to a different hash slot might cause client‑side routing issues, and how you would handle them.
  3. 3If you introduced client‑side sharding to split a hot key's data, what changes would you need in the application code and what pitfalls would you watch for?

5-8 years experience

  1. 1Design a strategy to prevent hot keys in a Redis Cluster used for session storage at 10 M QPS, covering data modeling, key distribution, and fallback mechanisms.
  2. 2How would you evaluate the impact of using Redis Cluster's hash tags versus a proxy layer to mitigate hot keys, and decide which to adopt?
  3. 3Discuss how you would monitor and automatically remediate hot keys in production, including alert thresholds and rebalancing actions.

8+ years experience

  1. 1At a company‑wide scale, you need to migrate existing services away from a hot‑key‑prone Redis Cluster to a more balanced architecture. Outline the migration plan, cross‑team coordination, and how you’d ensure zero downtime.
  2. 2What long‑term architectural patterns would you put in place to avoid hot keys across multiple Redis clusters, considering data partitioning, caching layers, and operational tooling?
  3. 3If a critical business metric depends on a hot key that cannot be split, how would you redesign the system to meet latency SLAs while keeping the key centralized?

Follow-up Questions

  • What metric would you monitor to detect a hot key early?
  • Can you walk me through how you’d update client routing after moving a hot key?
  • How would you test your hot‑key mitigation strategy before production rollout?
Share

Share via WhatsApp, X, Facebook, LinkedIn or copy link. Open Graph preview enabled.