Cache Invalidation Strategies

A product price changes in the database, but a customer still sees the old cached price. Removing or updating obsolete cached copies is called cache invalidation. It connects data changes with the copies used on reads.

Expiry, explicit deletion, refresh and versioned keys are different tools. The useful choice depends on acceptable staleness, write behaviour and failure handling. No single delete action makes every concurrent reader and every cache layer correct automatically.

A time to live, or TTL, expires a cached entry after a duration. In a simple cache-aside system, expired reads fetch the source again. This can bound reuse of a copy under the stated policy, but does not by itself resolve concurrent old fills or every served stale response.

Explicit invalidation removes affected keys after a change. If deletion fails, the update path needs retry, expiry or another repair mechanism. An event-driven invalidation system also needs duplicate, delay and ordering rules.

Versioned asset names give changed public files new identities, such as app.v2.css. The page must reference the new identity. Old pages can still request the old file, so publishing and retention must be coordinated.

Start an old read to capture source version 1. Publish version 2 and clear the cache. Finish the old read: the naive fill policy puts version 1 back in the empty cache.

Reset, choose the version-check guard, then repeat. The guard compares the captured version with the current source version at fill time and rejects the old fill. This model executes those checks atomically inside one local state object. A real distributed implementation needs a correct coordinated/versioned protocol; a separate check then set can still race.

Cache-aside reads fill on a miss while writes update the source and invalidate suitable copies. A write-through arrangement updates the cache as part of the write path, but separate source and cache operations still require a consistency and failure contract.

Write-behind can accept a cache-side change before the durable source is updated. That can change latency and durability risk. Do not confirm an important durable write without understanding what survives a cache failure.

Define authoritative versions, key ownership and stale-read tolerance. A cache should not silently become the owner of a fact simply because it is fast.

For public assets, versioned names can simplify publishing. For a changing catalogue display, a TTL plus explicit invalidation may be acceptable if the stale window is understood. For inventory allocation, enforce the authoritative write rule rather than relying on a possibly stale display copy.

HTTP caching documentation covers response reuse and validation; Redis documentation provides product context. Sources checked 6 October 2026. Application-level invalidation correctness still belongs to the design.

Test delayed readers, failed invalidation, duplicate events and a cold cache. Monitor freshness and source load; a synchronized expiry can produce a sudden burst of backend work.

Follow the Cache-Aside miss path and synchronous versus deferred cache writes to locate the race and acknowledgement boundary. Their names do not remove the concurrent refill problem explained here.

Expiry, deletion, refresh and versioning each have a role. State the tolerated stale window and the source of truth.

Account for pending readers, delayed events and failed updates. Validate the actual protocol instead of treating a cache delete as a universal correctness guarantee.