Back to Articles

Redis Caching Patterns: TTLs, Invalidation, and Cache Stampedes

Shaswat Raj
September 16, 20268 min read
Caching and distributed system architecture
Sketch

Sketch the mental model

Rebuild the system from memory. The canvas is editable and opens fullscreen when you need more room.

Redis is commonly introduced as a fast key-value store, but its real value in application architecture is more specific: it gives a service a very fast place to keep data that is cheaper to access than recomputing it or repeatedly reading a primary database.

What a cache actually does

A cache stores a copy of data closer to the code that needs it. A request checks the cache first. When the value is present, the application avoids an expensive database query or downstream API call. When it is absent, the application loads the source of truth and may populate the cache.

Cache-aside: the common pattern

In cache-aside, the application owns cache reads and writes. On a miss, it reads from the database and then stores the result in Redis with an expiry. This is simple and works well when the cache is an optimization rather than the canonical source of truth.

value = redis.get(key)

if value is missing:
    value = database.get(id)
    redis.set(key, value, ttl=300)

return value

TTL is a policy, not a magic number

A five-minute TTL is not automatically correct. The right value depends on how quickly data changes, how expensive stale data is, and how much database load the application needs to absorb. Short TTLs reduce staleness but create more misses.

Cache invalidation

When data changes, cached copies can become stale. One strategy is to delete or update the key whenever the source data changes. Another is to accept bounded staleness and rely on TTL expiration. The correct approach depends on the product requirement.

Hot keys and stampedes

A very popular key can become a hot spot. Worse, when a popular key expires, many requests can miss at once and all hit the database. This cache stampede can overwhelm the system precisely when traffic is high.

Common protections include request coalescing, randomized TTLs, stale-while- revalidate behavior, and proactive refresh of very hot data.

What Redis stores

Redis supports strings as well as structures such as lists, sets, sorted sets, hashes, and streams. The data structure should match the operation you need. For example, sorted sets are useful for ranked collections, while hashes can represent compact object-like records.

Cache consistency questions

  • Can users temporarily see an older value?
  • Which service is the source of truth?
  • What happens if Redis becomes unavailable?
  • How is a cache entry invalidated after a write?

When not to add Redis

A cache is not free. It adds another network hop, another failure mode, another data lifecycle, and operational overhead. Start by measuring the actual bottleneck. If the database query is already fast and traffic is low, adding a distributed cache may provide little value.

This is the same performance mindset used indatabase indexing: optimize the workload you can actually measure.