Cache Invalidation

After the source changes, the old copy becomes dangerous

If data changes in the primary store while the cache keeps returning the old value, a fast read becomes an incorrect read. Invalidation means removing or replacing a cached copy when it should no longer be considered current.

Delete or update

After a successful write, the corresponding key can be deleted. The next read gets a miss, loads the new version from the primary source, and populates the cache again. This approach is simple and does not require rebuilding the cached representation manually in the write path.

1. update primary store
2. delete cache key
3. next read reloads fresh value

Another option is to update the cache with the new value immediately. This avoids the next miss, but the application must know exactly what the cached representation should look like after the change.

Operation order matters

Imagine that the database update succeeds but deleting the cache key fails. The source now contains the new version, while readers keep receiving the old one. This means the cache operation also needs a clear retry and recovery strategy.

The reverse order is dangerous as well: if the cache is deleted first and the primary write then fails, a concurrent reader may manage to put the old value back into the cache.

One change can affect several keys

Sometimes one object participates in different representations: for example, an individual product card and several catalog pages. Changing the price then affects more than one key and may invalidate several related entries. The more derived representations there are, the harder invalidation becomes.