Redis Caching Strategies: The Performance Engineer's Playbook (2025)

Redis Caching Strategies: The Performance Engineer's Playbook (2025)

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

Adding Redis to your infrastructure is arguably the quickest way to achieve a 10x performance boost. However, it is also the easiest way to introduce stale data bugs, race conditions, and operational nightmares if mishandled.

Simply blindly executing set(key, value) is not a strategy; it's a liability. In this comprehensive playbook, we will analyze formal distributed caching patterns, determine when to apply them, and demonstrate how to architect robust defenses against the deadly "Thundering Herd" problem.

Part 1: Why Redis? (The Physics of Latency)

Why do we cache? Because Physics.

• L1 Cache Reference: 0.5 ns
• RAM Reference (Redis): 100 ns
• SSD Read (Postgres): 100,000 ns
• Network Roundtrip (AWS Region): 1,000,000 ns (1ms)

Reading from memory (Redis) is 1,000x faster than reading from disk (Postgres). Redis is Single-Threaded. It keeps all data in RAM. It uses an incredibly efficient event loop (epoll/kqueue). It can handle 100,000+ ops/sec on a single core.

Part 2: Caching Patterns

Strategy 1: Cache-Aside (Lazy Loading)

This is the most common pattern. The Application is in charge.

Read Flow:

1. App asks Cache for Key X.
2. Miss: App asks Database for X.
3. App keeps X in Cache.
4. App returns X.

Write Flow:

1. App writes X to Database.
2. App Deletes X from Cache (Don't update it—delete it. It's safer due to race conditions).

Pros:

• Resilient to cache failure (App just hits DB).
• Only caches what is actually requested (Cost efficient).

Cons:

• First request is slow (Cache miss penalty).
• Stale data gap (between DB write and Cache delete).

// Generic Cache-Aside Implementation
async function getUser(id: string) {
  const cacheKey = `user:${id}`;

  // 1. Check Cache
  const cached = await redis.get(cacheKey);
  if (cached) return JSON.parse(cached);

  // 2. Check DB
  const user = await db.users.find(id);

  // 3. Populate Cache (with TTL)
  if (user) {
    await redis.set(cacheKey, JSON.stringify(user), "EX", 3600);
  }

  return user;
}

Strategy 2: Write-Through

The Cache is the main entry point. The Cache updates the DB synchronously.

1. App writes to Cache.
2. Cache writes to DB.
3. Return success.

Pros: Data in cache is never stale. Cons: Writes are slower (2 hops). Hard to implement with Redis (requires application logic wrapping).

Strategy 3: Write-Behind (Write-Back)

The dangerous "High Speed" mode.

1. App writes to Cache.
2. App returns success immediately (0ms DB latency).
3. Cache asynchronously writes to DB later (Queued).

Pros: Insane write performance. Good for "Likes" or "Analytics". Cons: Data Loss. If Redis crashes before syncing to DB, the data is gone forever.

Part 3: The Cache Stampede (Thundering Herd)

Imagine you host the Super Bowl website. You have a key score. It expires at 12:00:00. At 12:00:01, 10,000 users request the score.

1. User 1 sees Miss -> Hits DB.
2. User 2 sees Miss -> Hits DB.
3. ...
4. User 10,000 sees Miss -> Hits DB.

Your Database dies. This is the Thundering Herd.

Solution A: Locking (Mutex)

Only let ONE process compute the value.

1. Check Cache. Miss.
2. Acquire Redis Lock (SETNX lock:score 1).
3. If acquired: Fetch DB, Update Cache, Release Lock.
4. If not acquired: Wait 50ms and retry step 1.

Solution B: Probabilistic Early Expiration (X-Fetch)

Store the value with a delta parameter. If TTL < delta, one random request decides to recompute it before it actually expires. The others interact with the strictly valid (but soon to be stale) cache.

Part 4: Advanced Uses (Beyond Key-Value)

Redis is more than a Dictionary.

4.1 Rate Limiting (The Sliding Window)

How to limit a user to 100 requests / minute? Don't use a simple counter (it resets strictly). Use a Sorted Set (ZSET).

1. Key: limiter:user_123.
2. Value: Timestamp of request. Score: Timestamp.
3. Logic:
   • Add current timestamp.
   • ZREMRANGEBYSCORE (Remove logs older than 1 min).
   • ZCARD (Count remaining logs).
   • If Count > 100, Reject.

This is atomic and accurate.

4.2 Pub/Sub

Real-time chat.

• User A subscribes to channel room:1.
• User B publishes to room:1.
• Redis pushes msg to User A. Note: Redis Pub/Sub is "Fire and Forget". If User A is offline, message is lost. Use Redis Streams for durable queues.

Part 5: Eviction Policies (When RAM runs out)

You have 10GB of RAM. You filled it. What happens on the next write? Configure maxmemory-policy:

1. noeviction: Return Error. (Bad for cache).
2. allkeys-lru: Delete the Least Recently Used key (regardless of TTL). Best for general caching.
3. volatile-lru: Delete LRU key that has a TTL. Keep persistent keys.
4. allkeys-random: Delete random keys. (Faster CPU, less accurate).

Part 6: Persistence (RDB vs AOF)

Redis is in-memory. If power fails, data is lost. Unless you persist.

RDB (Snapshots)

"Save the DB to disk every 5 minutes."

• Pros: Compact file. Fast restart.
• Cons: You lose the last 5 minutes of data.

AOF (Append Only File)

"Log every write command to disk."

• Pros: Durability (fsync every second).
• Cons: Big file. Slow restart.

Recommendation: For a pure Cache, maintain NO persistence. If it crashes, restart empty. The DB has the truth. For a Message Broker / Session Store, use RDB + AOF.

Conclusion: It's a Sharp Knife

Redis is a sharp knife. It cuts time, but it can cut you.

Best Practices Checklist

1. Always set a TTL. There is no such thing as permanent cache.
2. Use Namespaces. user:1, product:2. Don't just use 1.
3. Monitor Memory. If you hit swap, performance drops 1000x.
4. Handle Failures. Wrap Redis calls in try/catch. If Redis is down, fall back to DB (graceful degradation), don't crash the app.

Redis is likely the most "ROI positive" infrastructure piece you will own. Treat it with respect.