Cache Strategy Invalidation Expert

Core Capabilities

Architecture Patterns

Cache-Aside with Stampede Prevention

import { Redis } from 'ioredis';

const redis = new Redis();
const LOCK_TTL = 5; // seconds

async function cacheAside<T>(
  key: string,
  ttl: number,
  fetcher: () => Promise<T>
): Promise<T> {
  // Try cache first
  const cached = await redis.get(key);
  if (cached) return JSON.parse(cached);

  // Acquire lock to prevent stampede
  const lockKey = `lock:${key}`;
  const acquired = await redis.set(lockKey, '1', 'EX', LOCK_TTL, 'NX');

  if (!acquired) {
    // Another process is fetching — wait and retry
    await new Promise(r => setTimeout(r, 100));
    return cacheAside(key, ttl, fetcher);
  }

  try {
    const data = await fetcher();
    await redis.set(key, JSON.stringify(data), 'EX', ttl);
    return data;
  } finally {
    await redis.del(lockKey);
  }
}

Multi-Layer Cache Architecture

Request → L1: In-Process (LRU, 100ms TTL, ~1000 items)
              │ miss
              ↓
          L2: Redis (5-60min TTL, shared across instances)
              │ miss
              ↓
          L3: CDN (Cache-Control headers, edge-cached)
              │ miss
              ↓
          Origin (database/API)

Invalidation flows BACKWARD:
  Database change → Purge L2 (Redis DEL) → L1 expires via short TTL
                 → Purge L3 (Surrogate-Key purge / CDN API)

Event-Driven Invalidation

// On data change, publish invalidation event
async function updateUser(userId: string, data: UserUpdate) {
  await db.users.update(userId, data);

  // Invalidate all cache layers
  await redis.del(`user:${userId}`);
  await redis.del(`user:${userId}:profile`);

  // Publish for other instances' L1 caches
  await redis.publish('cache:invalidate', JSON.stringify({
    pattern: `user:${userId}:*`,
    timestamp: Date.now(),
  }));

  // CDN purge by surrogate key
  await cdn.purgeTag(`user-${userId}`);
}

Anti-Patterns

1. Cache everything — caching write-heavy, rarely-read data wastes memory and creates invalidation headaches
2. No TTL — every cache entry must expire; relying solely on explicit invalidation will eventually leave stale data
3. Cache-then-forget — monitor hit rate, eviction rate, and memory usage; an unmonitored cache silently degrades
4. Serializing full objects — cache only what you need; storing entire ORM models bloats memory and couples cache to schema
5. Invalidation by pattern scan — KEYS user:* blocks Redis; use sets to track related keys or hash structures

Quality Checklist

• Cache-aside pattern with stampede prevention (mutex or probabilistic refresh)
• TTL set on every key (no eternal cache entries)
• Hit rate monitored and >90% for primary caches
• Invalidation strategy defined: TTL-based, event-driven, or hybrid
• Cache keys include all relevant context (tenant, locale, version)
• Redis memory policy set (allkeys-lru for cache workloads)
• No KEYS * or SCAN in hot paths (use sets for key tracking)
• Multi-layer cache with clear TTL hierarchy (L1 < L2 < L3)
• Graceful degradation: app works (slower) if cache is down
• Cache warming strategy for cold starts after deployments