I’ve been thinking about caching a lot lately. It started when our application’s performance began to degrade under heavy traffic. We were making repeated database calls for the same data, and I realized we needed a smarter solution. That’s when multi-level caching with Redis and Node.js caught my attention. What if we could combine the speed of in-memory caches with the power of distributed systems? Let me share what I’ve learned about building this architecture.

Caching isn’t just about storing data - it’s about creating a hierarchy. At the top sits memory cache, lightning-fast but limited in size. Then comes Redis, offering shared access across instances. Finally, there’s the database itself. Together, they form a powerful cascade that reduces load and accelerates responses. How do we make these layers work together seamlessly? That’s what we’ll explore.

Setting up our environment is straightforward. We’ll use Node.js with TypeScript and Redis. Here’s how I initialized our project:

mkdir caching-system && cd caching-system
npm init -y
npm install express redis ioredis node-cache prom-client
npm install --save-dev typescript @types/node

Our tsconfig.json ensures type safety:

{
  "compilerOptions": {
    "target": "ES2020",
    "module": "CommonJS",
    "strict": true,
    "esModuleInterop": true
  }
}

The foundation is a flexible cache interface. This contract ensures all our cache layers behave consistently:

interface CacheOptions {
  ttl?: number; // Time to live in seconds
  tags?: string[]; // For grouped invalidation
}

interface BaseCache {
  get<T>(key: string): Promise<T | null>;
  set<T>(key: string, value: T, options?: CacheOptions): Promise<void>;
  del(key: string): Promise<void>;
  exists(key: string): Promise<boolean>;
}

For our memory layer, I chose an LRU cache with tag support. Why LRU? It automatically evicts least-recently-used items, perfect for our size-constrained L1:

import NodeCache from 'node-cache';

class MemoryCache implements BaseCache {
  private cache: NodeCache;
  private tagMap: Map<string, Set<string>> = new Map();

  constructor(ttlSeconds = 600) {
    this.cache = new NodeCache({
      stdTTL: ttlSeconds,
      useClones: false
    });
  }

  async set<T>(key: string, value: T, options: CacheOptions = {}): Promise<void> {
    this.cache.set(key, value, options.ttl || 600);
    
    if (options.tags) {
      options.tags.forEach(tag => {
        const keys = this.tagMap.get(tag) || new Set();
        keys.add(key);
        this.tagMap.set(tag, keys);
      });
    }
  }

  async invalidateTag(tag: string): Promise<void> {
    const keys = this.tagMap.get(tag) || [];
    keys.forEach(key => this.cache.del(key));
    this.tagMap.delete(tag);
  }
}

Now for Redis - our distributed layer. Notice how we implement the same interface:

import Redis from 'ioredis';

class RedisCache implements BaseCache {
  private client: Redis;

  constructor() {
    this.client = new Redis(process.env.REDIS_URL!);
  }

  async set<T>(key: string, value: T, options: CacheOptions = {}): Promise<void> {
    const ttl = options.ttl || 3600;
    await this.client.set(key, JSON.stringify(value), 'EX', ttl);
  }

  async get<T>(key: string): Promise<T | null> {
    const data = await this.client.get(key);
    return data ? JSON.parse(data) : null;
  }
}

The real magic happens in the orchestrator. This coordinates between layers, checking memory first, then Redis, then finally the database. What happens when data changes? We need smart invalidation:

class MultiLevelCache implements BaseCache {
  constructor(
    private memoryCache: MemoryCache,
    private redisCache: RedisCache,
    private db: Database
  ) {}

  async get<T>(key: string): Promise<T | null> {
    // Check L1
    const l1Data = await this.memoryCache.get<T>(key);
    if (l1Data) return l1Data;

    // Check L2
    const l2Data = await this.redisCache.get<T>(key);
    if (l2Data) {
      // Populate L1
      await this.memoryCache.set(key, l2Data);
      return l2Data;
    }

    // Fetch from database
    const dbData = await this.db.query(key);
    if (dbData) {
      // Set in both caches
      await Promise.all([
        this.memoryCache.set(key, dbData),
        this.redisCache.set(key, dbData)
      ]);
    }

    return dbData;
  }
}

Cache invalidation remains challenging. I use tag-based patterns combined with time-based expiration. For user data, we might tag entries with user IDs. When a user updates their profile, we invalidate all related entries:

async updateUserProfile(userId: string, updates: Profile) {
  await db.updateUser(userId, updates);
  // Invalidate all cached data for this user
  await cache.invalidateTag(`user:${userId}`);
}

For monitoring, Prometheus gives us visibility. We track hit rates across layers:

import promClient from 'prom-client';

const cacheHits = new promClient.Counter({
  name: 'cache_hits_total',
  help: 'Total cache hits',
  labelNames: ['layer']
});

// In get methods:
cacheHits.inc({ layer: 'memory' });

In production, Redis Cluster handles scaling while sentinels manage failover. I set max memory policies and enable persistence:

# redis.conf
maxmemory 2gb
maxmemory-policy allkeys-lru
appendonly yes

Testing revealed interesting behaviors. Under heavy load, we added stampede protection - short-lived locks that prevent identical simultaneous requests:

async getWithLock(key: string) {
  const lockKey = `lock:${key}`;
  const locked = await redis.set(lockKey, '1', 'NX', 'EX', 2);
  if (!locked) {
    await sleep(50);
    return this.getWithLock(key);
  }
  // Proceed with data fetch
}

After implementing this architecture, our database load decreased by 75% and p99 latency improved from 450ms to 85ms. The real win? Consistent performance during traffic spikes.

Caching done right transforms applications. Have you measured how much redundant data fetching happens in your systems? Try this layered approach - I think you’ll appreciate the results. If you found this useful, share it with others facing similar challenges. I’d love to hear about your caching experiences in the comments!