# Cache invalidation > Cache invalidation means removing or replacing cached data when the source of truth changes. In system design interviews, the hard part is defining how stale a read may be, then making that promise hold across concurrent reads, failed notifications, and multiple cache layers. Source: https://sysround.com/concepts/cache-invalidation Updated: 2026-11-05 ## How cache invalidation works Start with the freshness requirement and the cached keys. A restaurant edit might affect restaurant:42, nearby search results, and cached recommendation pages. Invalidating one object does not automatically refresh every derived view. List the affected caches, including application memory, shared caches, CDNs, and clients. TTL-based expiration removes an entry after a fixed lifetime. For example, a restaurant description cached for 60 seconds can remain outdated until it expires. TTL is simple and useful as a fallback, but it measures time since the cache fill, not time since the source changed; stale replicas and delayed fills can extend the actual staleness. With cache-aside, readers fetch from the database on a miss and populate the cache. A common write path commits the database update, then deletes the cached key so the next reader reloads it. Deleting before committing is unsafe because a reader can immediately refill the cache with the old database value. Deleting after commit still has a race: reader A fetches the old database value, writer B commits and deletes the key, then A inserts its old value. For stricter freshness, coordinate fills and invalidations with a per-key generation or version fence checked atomically when filling. Comparing against an existing cached version alone is insufficient once deletion removes that version. Event-driven invalidation uses change data capture or a transactional outbox to publish committed changes reliably. Consumers delete affected keys or apply versioned updates. Deletes can be retried, while updates need protection against out-of-order versions; a delayed duplicate delete can still cause an unnecessary miss. Monitor consumer lag and retain TTLs as a fallback. Other strategies include write-through updates and versioned keys. Write-through routes writes through a cache-aware layer, but coordinating cache and database failures still requires care. Versioned keys such as page:42:revision:8 keep immutable content separate; the mutable pointer to the current revision still needs a freshness policy. Whichever strategy you choose, protect the database from a burst of misses after invalidation. ## Worked example: Propagating a campaign pause to serving caches Suppose an ad system has 200 serving workers with local campaign caches. The requirement is that a paused campaign stop being eligible within five seconds. The pause transaction updates campaign 42 to version 18 and writes an outbox event. Workers consume the event and apply version 18, rejecting older updates. Each cached eligibility snapshot also has a maximum age of five seconds, measured from its authoritative validation rather than receipt of a delayed event. If a worker cannot revalidate an expired snapshot, it excludes the campaign. Immutable creative assets can stay cached. This trades some ad availability during outages for a bounded pause policy. ## Trade-offs - **Short TTLs versus cache efficiency.** Shorter lifetimes reduce how long cached entries survive but increase misses and database load without eliminating stale-fill races. - **Delete versus update.** Deleting avoids rebuilding values on the write path, while updating can preserve hit rates but requires correct ordering and handling of concurrent fills. - **Asynchronous invalidation versus immediate freshness.** Events decouple writes from cache availability, but delivery lag means successful writes can temporarily coexist with stale reads. - **Precise invalidation versus dependency tracking.** Targeting affected keys preserves cache hits but requires tracking dependencies, while broad invalidation is simpler and creates more misses. - **Serving stale data versus failing requests.** Stale content may be acceptable during an outage, but revoked permissions or disabled campaigns may require authoritative checks or failing closed. - **More cache layers versus more coordination.** Local caches and CDNs reduce latency but add copies that must expire, receive invalidations, or validate versions independently. ## When to use it in a system design interview - The design caches mutable records such as profiles, listings, restaurant pages, or campaign settings. - An edit or deletion must propagate to several cached or derived views within a stated deadline. - Multiple application instances keep local caches, so deleting a shared-cache entry is not enough. - The requirements include read-your-writes behavior, permission revocation, or preventing deleted content from returning. - A highly cached service must keep serving through database, cache, or event-delivery failures. ## How to bring it up in the interview - State a concrete freshness contract before choosing a strategy: descriptions may lag for 60 seconds, while authorization must be checked at access time. Interviewers will probe whether one policy really fits every field. - Draw the read and write timelines, including a reader that starts before a write and fills the cache afterward. Explain why database-then-delete is a baseline, not a complete concurrency guarantee. - Explain how committed changes reach invalidators reliably. Expect questions about a crash between database commit and event publication, duplicate delivery, consumer lag, and replay. - Separate ordinary content freshness from security and transaction correctness. A fresh-looking cache is not a substitute for an authoritative permission check or an atomic inventory reservation. - Describe operations as well as correctness: measure invalidation lag, cache hit rate, source-version lag, and miss traffic; use request coalescing or bounded refresh concurrency to contain refill bursts. ## Common mistakes - Saying that a 60-second TTL guarantees every read is at most 60 seconds behind the database, without accounting for delayed fills or stale source replicas. - Assuming database-then-delete eliminates all stale reads, or that sleeping and deleting again provides a correctness guarantee. - Publishing invalidation events with an unprotected dual write, leaving a crash window after the database commit. - Invalidating an object key while forgetting search results, cached lists, local process caches, or CDN responses that contain the same data. - Treating best-effort invalidation as sufficient for permission revocation, or purging a hot cache without planning for the resulting database traffic. ## Interview questions where it comes up - [Design an ads serving system](https://sysround.com/questions/design-ad-serving-system): Campaign pauses and targeting changes must reach serving-worker caches within an explicit freshness deadline. - [Design a dating app like Tinder](https://sysround.com/questions/design-tinder): Blocking and deletion must remain effective even when discovery feeds and profile views are cached. - [Design a login and authentication system](https://sysround.com/questions/design-authentication-system): Cached session validation needs a clear revocation bound and a deliberate policy when fresh validation is unavailable. - [Design Wikipedia or Notion](https://sysround.com/questions/design-wikipedia): Global page caches must reflect revision changes without exposing private content after access changes. - [Design a weather app](https://sysround.com/questions/design-weather-app): Cached observations and forecasts need version-aware publication and honest freshness during upstream outages. - [Design a parts compatibility feature](https://sysround.com/questions/design-parts-compatibility): Corrected compatibility evidence must invalidate affected lookup and discovery results before the correction deadline. - [Design Google Photos](https://sysround.com/questions/design-google-photos): Revocable album sharing requires coordinating cached metadata and media access with current permissions. - [Design a restaurant review app like Yelp](https://sysround.com/questions/design-yelp): Review edits and deletions must propagate to cached restaurant pages and rating summaries without leaving inconsistent views. ## FAQ ### What are the main cache invalidation strategies? The main options are TTL expiration, explicit deletion after writes, write-through cache updates, event-driven invalidation, and versioned keys. They are often combined: committed change events refresh data quickly, while expiration provides a fallback when events are delayed or missed. ### Should I update the cache or invalidate it after a database write? Deleting after the database commit is a common cache-aside baseline because the next read reconstructs the value from the source. Updating can avoid a miss, but concurrent writers and delayed events can overwrite newer data unless updates are version-aware. Neither approach alone prevents an older in-flight reader from repopulating stale data. ### What is the difference between cache invalidation and cache eviction? Invalidation removes or replaces data because it may no longer be correct. Eviction removes data to manage capacity, using a policy such as LRU. Expiration removes entries based on age and can support a freshness policy, but it does not detect source changes. ## Related concepts - [Caching strategies](https://sysround.com/concepts/caching-strategies) - [Eventual consistency](https://sysround.com/concepts/eventual-consistency) - [Change data capture](https://sysround.com/concepts/change-data-capture) - [Cache stampede and thundering herd](https://sysround.com/concepts/cache-stampede) --- SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.