> ## Documentation Index
> Fetch the complete documentation index at: https://akshanshgusain.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 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.