Caching strategies and the invalidation problem

Know your layers

Browser cache, CDN, reverse proxy, application cache and database cache each solve different problems. Understanding which layer is serving a response is essential when debugging stale content.

Caching at the highest useful layer gives the largest benefit, because it avoids the most work.

Common patterns

• Cache-aside — application checks cache, falls back to source, populates. Simple and most common.
• Read-through — the cache handles the miss.
• Write-through — writes go to both, keeping them consistent at some latency cost.
• Write-behind — fast writes, risk of loss on failure.

Invalidation approaches

Time-based expiry is simple and either serves stale data or expires too eagerly. Event-based invalidation is accurate and requires knowing every dependency. Tag-based invalidation groups related entries and is a good middle ground.

Choose deliberately per cache. Applying one strategy everywhere means some caches are stale and others provide little benefit.

The failure modes

Cache stampede: many requests miss simultaneously and overwhelm the source. Mitigate with locking or by refreshing slightly before expiry.

Also watch for caching user-specific data in a shared cache, which is a serious data leak, and for unbounded caches that grow until memory runs out. Both are common and both are avoidable with explicit key scoping and eviction policies.

Debugging a stale-content report

“The site is showing old content” is a common report and can originate at any layer. A systematic approach saves considerable time.

Work from the outside in: check the browser with cache disabled, then bypass the CDN, then the reverse proxy, then the application cache, then query the source directly. The layer at which the content becomes correct is the layer holding the stale copy.

Then fix the invalidation rather than clearing the cache. Manual cache clearing as a routine response means the invalidation logic is wrong and will keep producing the same reports.