Cache Invalidation

Imagine you have a web application that has products (like an online shop).

When someone visits a product page, usually you would:

• Query the database
• Get product info (name, price, description, images, related products)
• Build the page and show it to the user

This database call can be slow if you have millions of products or lots of visitors at the same time.

This is where cache can speed things up.

When the first person visits the page, you store the result from the database in a cache (like Redis or Memcached).

The next time someone visits the same product page, you don’t query the database again. You get the data from the cache instead, and since cache is very fast the page loads much quicker.

But what happens if an admin updates the product’s price? Some users might still see the old price because their page is coming from the cache.

That’s where cache invalidation comes in. This is the process of removing stale data so your users always get the most up-to-date information.

There are many ways to do this, let’s look at a couple of them.

Manual Invalidation

Manual invalidation is done by clearing or updating the cache in your code.

It’s usually done right after a data change, like when an admin updates a product or deletes a blog post.

It’s useful when updates don’t happen very often, for example on e-commerce websites or blog pages.

Time-based (TTL)

Time-based invalidation means you set a time limit for how long data stays in the cache. After that time ends, the data is removed or refreshed automatically.

It works well when data changes on a regular schedule and it’s okay if users see slightly old data for a short time.

It’s useful for things like news websites or weather data.

Write-through

Write-through means that every time you update or write data, you update the database and the cache at the same time.

This makes sure the cache always has the latest data. Users will never see old or wrong data from the cache.

The system usually updates the database first since it is the main source of truth. If the database update fails, nothing else happens. If the cache update fails, it can be retried later because the database still has the correct data.

Write-through is useful when you need to always show fresh data and don’t mind slightly slower writes.

Write-around

Write-around means when you update data, you write only to the database first. The write automatically invalidates (clears) the cache, so the next time the data is requested, it is fetched from the database and stored in the cache again.

The use case is similar to manual invalidation because both clear the cache instead of updating it immediately.

The main difference is that in write-around, cache invalidation happens automatically as part of the write process, while manual invalidation requires a separate action to clear the cache.

Write-behind

Write-behind caching means when you update data, you write it only to the cache first.

This makes writes very fast because they don’t wait for the database. But it risks losing data if the cache crashes before the data is saved.

An async job handles saving the cached data to the database, running at intervals or when a certain amount of data accumulates.

A good example of this is a social media app where users can like posts.

Each time someone clicks “like,” that action is first saved to the cache, so the app can update the like count instantly without waiting for the database.

Later, when enough likes have been collected (for example, every few seconds or after a certain number of likes), the app writes all these likes from the cache back to the database in one batch.

This reduces the number of direct writes to the database and helps keep the app fast and responsive, even when there are many users interacting at the same time.

Write-back

Write-back is similar to write-behind, data is also written to the cache first. The difference is that with write-back caching, data is written to the permanent storage only when the cache needs to free up space or when a specific event happens.

Think of a multiplayer gaming server that stores player session data in memory.

All updates are written to the cache first, which makes the game feel fast and smooth for players.

The data is only saved to the database when a player logs out or when the cache needs to clear up space.

This reduces the number of database writes and keeps the game server running quickly, even with many active players.

Event-based (Notification)

Event-based cache invalidation means you clear or update the cache when specific events happen in your system.

The cache listens for events like “product updated” and automatically updates or clears the relevant cached data.

Event-based cache invalidation is ideal for distributed systems, where components communicate through events to keep caches synchronized and data consistent across multiple servers or locations.

---