Scaling with Caching: Cache-Aside, Hot Keys, Stampede Protection, and Multi-Layer Caches

Scaling with Caching: Cache-Aside, Hot Keys, Stampede Protection, and Multi-Layer Caches

Caching helps an application scale by serving repeated reads from a faster layer instead of asking the source database or API to do the same expensive work again.

Start With Cache-Aside

For many backend workloads, cache-aside is the simplest useful pattern:

1. Read from cache.
2. On miss, read the source of truth.
3. Store the result with a TTL.
4. Return it.

Redis's current guidance recommends invalidating the cache when authoritative data changes rather than trying to make the cache another source of truth.

Cache at the Right Layer

Different caches solve different problems:

• CDN/edge cache — public/static HTTP responses and assets.
• In-process cache — tiny hot data where per-instance staleness is acceptable.
• Distributed cache — shared reusable data across application replicas.
• Database/internal cache — engine-specific page/query acceleration.

Do not add Redis when a CDN or small local cache already solves the bottleneck.

Prevent Cache Stampedes

When a hot key expires, hundreds of requests can miss simultaneously and hammer the database.

Useful defenses include:

• request coalescing / single-flight
• small randomized TTL jitter
• proactive/early refresh
• bounded fallback concurrency

The goal is that one miss refreshes the value while the rest avoid duplicating the same expensive work.

Handle Hot Keys

One extremely popular key can overload a single cache shard or network path. Depending on the workload, local near-caches, replication, or splitting/reshaping the cached value can help.

Measure before redesigning—the bottleneck may be serialization or network bandwidth rather than Redis CPU.

Negative Caching

Repeated requests for nonexistent data can still hammer the database. Cache a short-lived “not found” result when safe, using a shorter TTL than normal data so newly created records do not stay invisible for long.

Plan for Cache Failure

A cache outage can suddenly send all traffic to the database. Protect the source with connection/concurrency limits and avoid retry storms.

If the database cannot survive even bounded cache-miss traffic, the cache has become a hidden single point of failure.

Measure the Cache

Track:

hit ratio
miss rate
p95/p99 cache latency
evictions
memory usage
hot keys
origin/database load
stampede events

A high hit ratio is only valuable if it meaningfully improves latency or removes load from the constrained source.

Final Takeaway

Caching scales reads when reuse is real. Start with cache-aside, invalidate on authoritative writes, protect hot expirations from stampedes, choose the correct cache layer, and design the database to survive controlled cache misses.

References

• Redis: Cache-Aside Pattern
• Azure Architecture Center: Cache-Aside Pattern
• Cloudflare Cache Documentation