Distributed Caching Patterns: Cache-Aside, Write-Through, and Cache-Stampede Mitigation

1. Fundamentals of Distributed Cache Topology

In monolithic architectures, local in-memory caches (such as Guava or local Node.js maps) provide microsecond retrieval speeds. However, in horizontally scaled microservices environments with hundreds of replicas, local caching leads to catastrophic state divergence and duplicate database reads.

A distributed cache—principally Redis in Cluster mode—pools memory across distributed nodes partitioned via consistent hashing across 16,384 hash slots. This delivers sub-millisecond key-value operations while guaranteeing that all application pods access a unified, synchronized view of cached domain entities.

2. Access Patterns: Cache-Aside vs. Write-Through

Choosing the appropriate caching pattern dictates consistency guarantees and recovery behavior during database write operations.

3. Solving the Cache Stampede (Dogpiling) Problem

A cache stampede occurs when a high-traffic key (e.g., the home page payload or a top-tier product catalog entry) expires. In that exact millisecond, hundreds or thousands of concurrent requests observe a cache miss and simultaneously assault the primary database with identical heavy queries.

To prevent complete database exhaustion, engineers apply the XFetch algorithm (probabilistic early expiration) or distributed mutex locking. With XFetch, read requests calculate a dynamic probability of refreshing the cache before the TTL hard expiration occurs based on the computational cost of the query.

import Redis from 'ioredis';

const redis = new Redis();

interface CachedItem<T> {
  value: T;
  delta: number; // Duration taken to compute value in ms
  expiry: number; // Unix timestamp
}

// XFetch probabilistic early refresh algorithm
export async function getWithXFetch<T>(
  key: string,
  ttlSeconds: number,
  computeFn: () => Promise<T>,
  beta: number = 1.0
): Promise<T> {
  const raw = await redis.get(key);

  if (raw) {
    const item: CachedItem<T> = JSON.parse(raw);
    const now = Date.now();
    // Probabilistic early recomputation calculation:
    // If -delta * beta * ln(random) > (expiry - now), recalculate asynchronously!
    const timeRemaining = item.expiry - now;
    const shouldEarlyRecompute = -item.delta * beta * Math.log(Math.random()) > timeRemaining;

    if (!shouldEarlyRecompute) {
      return item.value;
    }
  }

  // Compute fresh value, measure execution time delta
  const start = Date.now();
  const freshValue = await computeFn();
  const delta = Date.now() - start;

  const toCache: CachedItem<T> = {
    value: freshValue,
    delta,
    expiry: Date.now() + ttlSeconds * 1000,
  };

  await redis.set(key, JSON.stringify(toCache), 'EX', ttlSeconds);
  return freshValue;
}

4. Memory Sizing & Eviction Policies in Production

Redis operates entirely in RAM. When maxmemory limits are reached, the configured maxmemory-policy governs how keys are reclaimed.

For general-purpose caching, volatile-lru (Least Recently Used among keys with TTLs) or allkeys-lfu (Least Frequently Used) prevents memory out-of-bounds crashes while shielding active session data.

5. Distributed Locking with Redlock: Reality vs. Pitfalls

When coordinating atomic updates across decoupled microservices (such as preventing double-booking of a seat), distributed locks are frequently introduced. While Redis Redlock across multiple independent nodes provides high reliability, engineers must account for clock drift and garbage collection pauses.

Always append fencing tokens (monotonically increasing version integers) to distributed lock claims to guarantee that stale workers paused by garbage collection cannot commit invalid mutations.

6. Frequently Asked Questions