Redis Caching Patterns I Consider in Production Systems

Caching is not only a performance technique. It is a consistency decision.

Redis can reduce repeated database work and improve response time for read-heavy paths, but every cache introduces the possibility of stale data. The question is whether the product can tolerate that trade-off and whether the team understands the invalidation model.

Cache-Aside

A common pattern is cache-aside:

Request
-> Redis
   -> cache hit: return
   -> cache miss: PostgreSQL
-> populate Redis
-> return

The application checks Redis first. If the value exists, it returns it. If not, the application reads from PostgreSQL, stores the result in Redis, and returns it.

This pattern is straightforward, but it means the application owns cache population and invalidation.

Write-Through

In a write-through style, writes update the cache as part of the write path. The benefit is that cached data may stay fresher after writes. The cost is more complexity and more work during mutation paths.

Write-through can be useful when the write model is well controlled and the cache is part of the expected read path.

Write-Behind

Write-behind updates the cache first and persists later. This can improve perceived speed, but it raises the consistency risk. If the process fails before persistence, data may be lost or become inconsistent.

I would be cautious using this pattern for important business state.

TTL Choices

TTL should follow business requirements. Data that changes rarely can tolerate a longer TTL. Data that affects user permissions, money-like state, or sensitive workflows may require short TTLs or no caching.

Avoid choosing expiration values because they sound familiar. Choose them because the product can tolerate that amount of staleness.

Cache Invalidation

Invalidation is difficult because the database and cache can disagree:

Database updated
-> cache still contains old value

Common strategies include explicit invalidation, versioned keys, short TTLs, and event-driven invalidation. Each has trade-offs.

Explicit invalidation is direct but easy to miss. Short TTLs are simple but can increase database load. Event-driven invalidation can be powerful but adds messaging and failure modes.

Cache Stampede

A cache stampede happens when many requests miss at the same time and all query the database.

Strategies include locking, request coalescing, staggered expiry, and refreshing hot keys before expiry. The right choice depends on traffic and data shape.

What Not to Cache

I avoid caching highly volatile data without a clear strategy. I avoid sensitive data unless access, encryption, and lifecycle are understood. I avoid caching values where stale data is unacceptable.

The Education Rewards Platform includes Redis as part of the backend technology context. That is a reminder that caching and background operations often sit near transactional systems, but the correctness model must remain explicit.

Principle

Cache because you understand the data-access pattern, not because Redis is available.