Redis Caching Strategies for Production Apps

Why Redis?

Redis (Remote Dictionary Server) is an in-memory key-value data store. Because it stores data in RAM instead of on a hard drive, it can deliver sub-millisecond response times, capable of handling millions of requests per second.

However, RAM is expensive and volatile. Therefore, Redis is most commonly used alongside a primary database (like PostgreSQL) as a caching layer.

1. Cache-Aside (Lazy Loading)

This is the most common caching strategy. The application talks to both the cache and the database.

async function getUserProfile(userId) {
  // 1. Check Cache first
  const cacheKey = `user:${userId}:profile`;
  const cachedData = await redis.get(cacheKey);
  
  // Cache HIT! Return immediately
  if (cachedData) {
    return JSON.parse(cachedData);
  }
  
  // 2. Cache MISS! Fetch from primary database
  const user = await db.query('SELECT * FROM users WHERE id = ?', [userId]);
  
  if (user) {
    // 3. Write to cache for next time, set a TTL (Time To Live)
    await redis.set(cacheKey, JSON.stringify(user), 'EX', 3600); // Expire in 1 hour
  }
  
  return user;
}

2. Write-Through Caching

In this strategy, data is written into the cache and the corresponding database at the exact same time. The cache acts as the primary interface.

async function updateUserName(userId, newName) {
  // 1. Update Database
  await db.query('UPDATE users SET name = ? WHERE id = ?', [newName, userId]);
  
  // 2. Update Cache immediately
  const cacheKey = `user:${userId}:profile`;
  
  // Fetch full updated object or just update the specific field
  const updatedUser = await db.query('SELECT * FROM users WHERE id = ?', [userId]);
  await redis.set(cacheKey, JSON.stringify(updatedUser));
  
  return updatedUser;
}

3. Write-Behind (Write-Back) Caching

The application writes data ONLY to the cache and returns immediately. A background process asynchronously syncs the cache data to the primary database later.

Highly performant for write-heavy workloads (like counting YouTube views or tracking live game scores), but risks data loss if the cache server crashes before the sync happens.

The Hardest Problem: Cache Invalidation

Phil Karlton famously said: "There are only two hard things in Computer Science: cache invalidation and naming things."

How do you ensure users don't see old data? Here are the top strategies: