🧩 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