🧩 Problem Definition

A hot key is a cache key that receives disproportionately high traffic, overwhelming:

Redis
CPU
Network
Single thread / shard

Even with:

Request coalescing
TTL jitter
Distributed locks

Naive Cache (Why It Fails)

❌ What happens

Millions of reads/sec to same key
Redis single-thread bottleneck
P99 latency explodes

Solutions

🧩 Strategy A — Local In-Process Cache (L1 Cache)

🔹 Idea

Don’t hit Redis for every request
Cache hot key inside app memory

✅ Code (JS)

let localCache = null;
let lastUpdated = 0;

async function getHotKey() {
  if (Date.now() - lastUpdated < 1000 && localCache) {
    return localCache;
  }

  const value = await redis.get("hot_key");
  localCache = value;
  lastUpdated = Date.now();
  return value;
}

Why Better Than Previous

✔ Removes Redis from hot path
✔ Microsecond access
❌ Stale data risk

🧩 Strategy B — Key Sharding (Breaking the Hot Spot)

🔹 Idea

Split one hot key into multiple sub-keys

hot_key:1
hot_key:2
hot_key:3

✅ Code

function shardKey(key, shards = 10) {
  const shard = Math.floor(Math.random() * shards);
  return `${key}:${shard}`;
}

async function getHotKey() {
  return redis.get(shardKey("hot_key"));
}

Why Better

✔ Load spread across Redis
✔ Linear scalability
❌ Write complexity increases

🧩 Strategy C — Push-Based Updates (Best ⭐)

🔹 Idea

Redis pushes updates
Apps don’t poll

✅ Code (Redis Pub/Sub)

redis.subscribe("hot_key_updates");

redis.on("message", (_, msg) => {
  localCache = JSON.parse(msg);
});

Why This Beats All Previous

✔ Near-zero latency
✔ No Redis reads
✔ Perfect for live feeds

🧠 Final Comparison Table (Interview Gold)

Strategy	Redis Load	Latency	Complexity
Naive	🔥🔥🔥	High	Low
L1 Cache	🔥	Low	Medium
Sharding	🔥🔥	Medium	High
Push	🟢	Ultra Low	High

When One Key Becomes a Bottleneck: Solving the Hot Key Problem