How Cache Knows Data Is Updated: TTL, Invalidation & Events

Chandan Rajpurohit

Sep 24

5 min read

Caching is one of the most common techniques used to make applications faster.

Instead of fetching the same data from a database or API every time a user requests it, an application can temporarily store that data in a cache. The next request can then be served much faster.

But this raises an important question:

If the original data changes, how does the cache know that its copy is no longer correct?

The short answer is: a cache usually does not magically know. The application or caching system needs a mechanism to detect, expire, invalidate, or revalidate the cached data.

Let’s understand how this works.

Table of Contents

What Is a Cache?

Imagine an application has a product page.

Without caching, every request might follow this path

If thousands of users request the same product, the database may have to perform the same work thousands of times.

With caching:

If the data is already in the cache, the application can return it without querying the database.

For example, suppose the database contains:

Product: Laptop Price: ₹60,000

The application stores this in the cache: product:product_id (is the cache key) → ₹60,000 (is the cached value)

Later, someone changes the price in the database to: ₹55,000

Now we have a problem.

The database says ₹55,000, but the cache still says ₹60,000.

So how do we prevent users from receiving stale data?

Time-To-Live (TTL)

One of the simplest approaches is expiration.

When data is stored in the cache, we give it a lifetime.

For example:

Cache:
product:product_id
value: ₹60,000
TTL: 60 seconds

After 60 seconds, the cached value expires.

The next request goes back to the database, retrieves the latest value, and stores it in the cache again.

The advantage is simplicity.

The disadvantage is that the cache can remain stale until the TTL expires.

For example, if the price changes immediately after the cache is created and the TTL is one hour, users could potentially see the old price for almost an hour.

Cache Invalidation

Another common approach is cache invalidation.

Instead of waiting for the cache to expire, the application explicitly removes or updates the cached data when the original data changes.

Suppose the application updates a product:

Database:
₹60,000 → ₹55,000

After successfully updating the database, the application can remove the corresponding cache entry:

DELETE product:product_id

The next request won't find the value in the cache, so the application fetches the latest value from the database.

This is often described as

This approach can keep cached data relatively fresh, but it requires developers to correctly handle invalidation.

That is why you'll often hear the phrase:

"Cache invalidation is one of the hard problems in computer science."

Updating the Cache Directly

Instead of deleting the cache, the application can update it at the same time as the database.

For example:

Database:
₹60,000 → ₹55,000

Cache:
₹60,000 → ₹55,000

Now both contain the latest value.

This can be efficient, but it introduces another problem: keeping two systems consistent.

What happens if the database update succeeds but the cache update fails?

You could end up with:

Database → ₹55,000
Cache    → ₹60,000

So applications need to think carefully about failure handling.

Version Numbers

Some systems use versions to determine whether cached data is current.

For example:

Product version: 10

The cache stores:

Value: ₹60,000 Version: 10

When the product changes:

Version: 11 Value: ₹55,000

If the application discovers that its cached version is 10 while the current version is 11, it knows that the cache is stale.

Versioning is particularly useful when you need to distinguish between different generations of data.

ETags and Conditional Requests

HTTP caching has another interesting mechanism: ETags.

Suppose an API returns:

ETag: "v12"

The client can save that ETag along with the response.

Later, instead of downloading the entire resource again, it asks the server:

If-None-Match: "v12"

The server checks whether the resource has changed.

If it hasn't changed:

304 Not Modified

The client can continue using its cached copy.

If it has changed, the server returns the new resource with a new ETag.

Conceptually:

This saves bandwidth while still allowing the client to verify freshness.

Cache-Control Headers

HTTP also provides cache-control mechanisms that tell browsers and intermediary caches how long a response can be reused.

For example:

Cache-Control: max-age=3600

This essentially tells a cache that the response can be considered fresh for a specified period.

Other directives can require revalidation or prevent caching altogether, depending on the application's requirements.

This is commonly used for websites, APIs, CDNs, and browser caching.

The Cache Doesn't Always Know

This is the most important concept.

A cache generally does not watch your database and automatically understand that something changed. Unless something connects these two systems, the cache has no inherent knowledge that the database changed.

The application needs a strategy such as:

Expiration/TTL
Cache invalidation
Updating the cache
Version checking
Conditional requests
Database change events
Pub/sub notifications
Revalidation

Why Can't We Just Always Use the Database?

We could, but caching exists because databases and other backend systems can become expensive or slow under heavy workloads.

Caching can provide:

Lower latency
Fewer database queries
Better scalability
Reduced network traffic
Faster responses
Lower infrastructure load

The trade-off is data freshness and consistency.

The more aggressively you cache data, the more carefully you need to design how updates propagate.

The Big Picture

There isn't one universal way that a cache knows data has changed.

Different systems use different strategies:

The key idea is simple:

Caching is not just about storing data. It is also about deciding when that stored data can no longer be trusted.

Once you understand that, concepts like TTL, cache invalidation, ETags, versioning, and cache revalidation become much easier to understand.

A cache doesn't usually "know" that data has changed by itself.

Instead, the system around the cache provides a mechanism to determine freshness.

For simple applications, a TTL may be enough.

For applications where stale data is unacceptable, explicit invalidation or event-driven updates may be necessary.

And for HTTP clients and CDNs, mechanisms such as ETags and Cache-Control allow caches to efficiently determine whether their stored response is still usable.

So whenever you design a caching system, don't only ask:

"How do I cache this data?"

Also ask:

"How will I know when this data is no longer valid?"

That second question is where good cache design really begins.

Frequently Asked Questions (FAQs)

How does a cache know when data has changed?

A cache usually does not automatically know when the underlying data changes. Applications use mechanisms such as TTL, cache invalidation, events, versioning, or HTTP revalidation to determine when cached data needs to be refreshed.

What is cache invalidation?

Cache invalidation is the process of removing or marking cached data as invalid when the underlying data changes. The next request can then fetch the latest data and store it in the cache.

What is TTL in caching?

TTL (Time To Live) defines how long cached data remains valid. Once the TTL expires, the cache considers the data stale and can fetch fresh data from the source.

Does TTL guarantee that cached data is always fresh?

No. TTL only defines how long data can remain cached. If the underlying data changes before the TTL expires, the cache may continue serving the old value until the cache entry expires or is explicitly invalidated.

What is the difference between cache expiration and cache invalidation?

Cache expiration happens automatically after a predefined period such as a TTL. Cache invalidation happens when the application explicitly removes or marks cached data as invalid, usually because the underlying data has changed.

What is an ETag in HTTP caching?

An ETag (Entity Tag) is an identifier that represents a specific version of an HTTP resource. Clients can send the ETag using If-None-Match to check whether their cached copy is still current. If the resource has not changed, the server can return 304 Not Modified.

What is event-driven cache invalidation?

Event-driven cache invalidation uses events or notifications to inform the cache or application that specific data has changed. The cache can then delete, refresh, or update the affected entry instead of waiting for its TTL to expire.