Application caching: expiry times, invalidation and stampede protection

What it is

In the cache-aside pattern, the application queries the cache first. On a miss, it reads the source, stores the result with an expiry time and returns it. Redis documents the building blocks: EXPIRE sets a time limit, after which the key is deleted automatically, and SET with the NX option writes only if the key does not yet exist, which is the basis for a simple lock. At the HTTP level, RFC 9111 uses max-age to apply the same principle of limited freshness. Application caches follow no standard, so you define their rules yourself.

Why it matters

A cache reduces load and latency, but a stale entry after a write is a correctness bug that is hard to reproduce. It occurs only in the window between the write and the expiry, and it disappears when you try to recreate it. The invalidation strategy is therefore part of the design, not a later fix.

How to apply

• Decide per data class how old a value may be, and set the expiry time accordingly. A short expiry limits the damage of any forgotten invalidation.
• On writes, delete the affected keys instead of overwriting them. Deletion is idempotent and cannot leave an older value behind when two writers overtake each other. A reader that is overtaken by a write between the database read and the cache write can still store a stale value; only the expiry time limits this window.
• Include a version or schema identifier in the key (kunde:v3:123), so that a deployment with a new value structure does not read old entries. The old entries expire on their own.
• Consider derived keys: when an object changes, the lists, counters and search results that contain it are affected too. Either delete their keys as well or give them a shorter expiry.
• Prevent a stampede: when a hot key expires, only one request should query the source. With SET sperre:<schlüssel> 1 NX EX 5, one process obtains the right to reload; the others wait briefly or serve the old value if it is still present. The Redis documentation calls SET … NX EX a simple lock and points to Redlock for fault-tolerant locks. For stampede protection, where a failure only means a second reloader, the simple form is sufficient.
• Cache negative results ("not found") with a short expiry if many requests target missing keys.
• Measure the hit rate and the load on the source. A cache without hits only adds latency on every miss.

Pitfalls

User-specific data stored under a shared key. Treating the cache as durable storage even though a restart empties it. Expiry times that are set and checked on different hosts with differing clocks. A lock without an expiry time that is never released after the reloading process crashes.