Invalidation, TTL & Failure Modes

TTL — Bounding Staleness

A TTL expires an entry after a fixed duration regardless of whether the underlying data changed. Longer TTL = better hit rate, less load on the source, more staleness risk. Shorter TTL = fresher data, more source load, lower hit rate. Different data in the same system often warrants very different TTLs — a profile picture URL vs. a stock price.

Explicit Invalidation

Instead of waiting for TTL, actively delete/update the cache entry when the write happens. Tighter consistency, but every mutation path must remember to invalidate — a missed path is a classic stale-cache bug.

async function updateUser(id, data) {
  await db.users.update(id, data);
  await cache.delete(`user:${id}`);  // don't forget this on every write path
}

Thundering Herd / Cache Stampede

When a popular entry expires, many concurrent requests miss simultaneously and hammer the source at once. Mitigate with request coalescing (only one request refreshes, others wait), jittered TTLs, or stale-while-revalidate (serve the stale value immediately while refreshing in the background).

Negative Caching

Cache a "not found" result too, so repeated lookups for a missing item don't keep re-hitting the source. Use a shorter TTL than positive entries — otherwise a newly-created item can be masked as missing until the stale negative entry expires.

Cache Key & Security Gotchas

A key that's too broad can serve the WRONG data to a different context — e.g. caching a per-user response by URL alone, omitting the user ID, can leak one user's data to another. Personalized/sensitive responses need Cache-Control: private (or no shared caching) rather than a public/shared cache.

Multi-Node Consistency

With per-server local caches, a write on one server doesn't update another server's local cache — it keeps serving stale data until its own TTL expires. This is why frequently-changing shared data often lives in a centralized cache (Redis) rather than purely per-process memory.