Cache Invalidation Strategies – "How You Keep Cache Up-to-date"

Cache invalidation strategies focus on removing or updating stale data from the cache when the source of truth (e.g., DB) changes:

Strategy	Description	Pros/Cons
Explicit Invalidation	Manually remove/update cache on data change	Precise but needs app-level logic
TTL (Time-to-Live)	Items expire after fixed time	Easy, but can serve stale data
Versioned Keys	Use version in cache key, change version to invalidate	Avoids collisions, but uses more memory
Event-based Invalidation	DB changes publish events to update caches	Good for distributed systems
Write-through/Write-behind	Auto-updates cache during writes	More consistent, but write-heavy

Cache invalidation refers to the process of removing or updating stale data in a cache to ensure that clients receive fresh and accurate information from the underlying data source. Choosing the right invalidation strategy is crucial for balancing performance with data correctness, especially in distributed systems.

Time-based Expiration (TTL)

Cached items are automatically invalidated after a defined time interval (Time To Live). This is simple and effective for infrequently changing data but can lead to stale data being served if updates occur before expiration, or increased database load if too short.

Event-based Invalidation

Cache entries are invalidated immediately upon a data update event. This can involve:

Direct Invalidation: Invalidate exact keys when the associated data changes.

Pattern Invalidation: Invalidate all keys matching a pattern (e.g., all products for a category).

Cascading Invalidation: Invalidate related cache entries (e.g., user invalidation affects user profile, user posts, etc.).

Write-through/Write-behind Cache

Write-through: Every write operation updates both the cache and data store, ensuring immediate consistency but with increased write latency.

Write-behind: Updates are written to the data store after being cached, allowing faster writes but risking temporary inconsistency.

Version-based Invalidation

Cache entries are tagged with a version number. When data changes, the version increments; stale cache can be detected and refreshed accordingly. Common for highly dynamic data.

Manual/Purge-based Invalidation

Caches are manually or programmatically purged based on certain triggers or as needed. Useful when updates are relatively rare or can be tightly controlled.

Stale-while-revalidate

Cached entries past their TTL are served as “stale” while asynchronously fetching the latest version from the source. This enables low-latency reads while still keeping cache updated in the background.

Distributed Cache Invalidation Strategies

Centralized Invalidation (Conductor Pattern)

A centralized system (like a message queue or Redis) broadcasts invalidation messages to all cache servers.

Gossip Protocols

Servers communicate cache changes peer-to-peer, propagating the invalidation through the network. Useful for large-scale, decentralized systems.

Lease-based Invalidation

Servers are given a temporary “lease” on cache data; when the lease expires, data is automatically invalidated unless explicitly renewed.