Distributed Caching: Memcached, Hashing & Hot Keys

When one Redis instance is not enough, you scale horizontally. Consistent hashing maps cache keys to nodes in a ring — when you add or remove a node, only a fraction of keys need to move, not the entire dataset. Redis Cluster implements this natively with 16,384 hash slots distributed across nodes. Memcached is Redis's simpler cousin: pure key-value, no persistence, no data structures, multi-threaded. Choose Memcached when you need a dumb, fast, large cache with no durability requirements. Choose Redis when you need data structures, persistence, pub/sub, or atomic operations. The hot key problem occurs when a single key (celebrity profile, breaking news article) receives disproportionate traffic, overwhelming one cache node. Solutions: local in-process caching of hot keys (L1), read replicas for that key, or splitting the key into multiple sub-keys (hot:article:123:shard-1 through shard-N) and aggregating on read.

// 100k req/sec all hit one key on one node
const article = await redis.get('article:breaking-news');
// Node CPU at 100%, other nodes idle

const localCache = new LRUCache({ max: 100 });

async function getArticle(id) {
  // L1: in-process (nanoseconds)
  const local = localCache.get(id);
  if (local) return local;

  // L2: Redis (milliseconds)
  const cached = await redis.get(`article:${id}`);
  if (cached) {
    const article = JSON.parse(cached);
    localCache.set(id, article);
    return article;
  }

  const article = await db.articles.findById(id);
  await redis.setex(`article:${id}`, 60, JSON.stringify(article));
  localCache.set(id, article);
  return article;
}