Introduction the unexpected challenge of Cache Invalidation

Hi all, a few months ago, I was working on an internal analytics platform we built for our operations team. It wasn’t a flashy consumer product or a major internal tool, just a simple dashboard where our team logged in to view:

• Daily metrics

• Reports generated from logs

• Small charts based on processed data

Pretty boring stuff from the outside. But inside, it was doing a surprising amount of work: aggregations, joining multiple datasets, generating status summaries, filtering user activity logs, and more.

Everything was fine until people actually started using it. At around 80-100 internal users, the dashboard started to behave like a tired laptop running Chrome with 30 tabs slow page loads, spiky response times, and the occasional warning from our database monitoring tool. The app wasn’t crashing, but it wasn’t happy either.

I thought, Fine, let’s add a caching layer. This will be a quick win, a no-brainer.

I was wrong. Caching made things fast, but invalidation became the real monster.

This article is about that journey and how I eventually solved cache invalidation without relying on SCANs, massive deletes, or complicated dependency graphs at scale.

Added Basic HTTP Caching Starting with Simple Solutions

I began with a straightforward approach: browser caching, before delving into Redis or more advanced caching strategies. Most of our dashboard API responses were user-specific, meaning that if multiple users accessed the “Analytics > Traffic Summary” page, they would all receive the same JSON data.

To address this, I implemented:

• Cache-Control headers

• ETag headers

E-Tag Approach

Whenever the dashboard fetched data, I generated a small fingerprint of the response ETag: "bd3a91ca"

When the browser requested the same endpoint again, it sent If-None-Match: "bd3a91ca"

If the data hadn’t changed, the server responded with 304 Not Modified. This resulted in zero body transfer and instant load times.

While this approach significantly reduced our response sizes, the API still performed all the intensive computations to verify if the data had changed. Browsers don’t store server-side logic, so the backend still needed to compute data to generate the ETag. Consequently, latency improved, but the server load remained largely unchanged.

Redis Caching Layer The Initial Boost and Its Pitfalls

Next, I implemented a Redis caching layer using the classic cache-aside strategy, which is one of the most common caching techniques. The logic was straightforward:

if (cachedResponseExists):
    return cachedResponse
else:
    compute → cache it → return it

With this approach, performance skyrocketed. The dashboard became incredibly fast, and for a moment, it felt like I had unlocked some secret engineering nirvana. However, this bliss was short-lived. When changes occurred in the underlying data, the cached data became outdated, and the system faced significant challenges.

Explore Further
What are some alternative caching strategies you might consider if cache-aside doesn't meet your needs? How do they compare in terms of complexity and efficiency?

The Hidden Enemy Cache Invalidation

Everything was fast until the day the analytics pipeline ran a reprocessing job. This job updated

• Daily totals

• Error counts

• Processed stats

Suddenly, users were looking at yesterday’s numbers. No one could tell which data was fresh and which was stale. Fixing stale data at scale is trickier than it sounds. The real question became?

How do I invalidate multiple cached keys without knowing what they are?

Cache invalidation is challenging because it requires identifying and removing outdated data from the cache to ensure users receive the most current information. This is crucial because stale data can lead to incorrect analytics, poor user experience, and potential business decisions based on outdated information.

Each dashboard page had:

• Summary cache

• Detailed cache

• Sub-sections cache

• Chart data cache

• Metadata cache

All of these caches depended on the same underlying dataset. When the data changes, all related cached entries must be invalidated to reflect the updates accurately.

Example of Cache Keys:

Consider a scenario where you have cache keys like:

• summary:2025-11-27

• details:user123:2025-11-27

• chart:traffic:2025-11-27

• metadata:2025-11-27

Managing these keys can quickly become overwhelming. If the underlying data changes, you need to invalidate all related keys. However, without a clear mapping of which keys are affected by which data changes, this process can become unmanageable. You might end up with stale data being served because some keys were missed during invalidation.

“There are only two hard things in Computer Science: cache invalidation and naming things.”

This quote highlights the complexity of cache invalidation, as it requires a precise understanding of data dependencies and efficient strategies to manage and invalidate cache keys without causing performance bottlenecks or data inconsistencies.

Attempt at Fixing Invalidation Client-Side Versioning

I took inspiration from Content Delivery Networks (CDNs) and their approach to versioning assets. CDNs typically don't delete old assets; instead, they serve assets with versioned URLs, such as app.css?v=42. This method allows browsers to cache assets efficiently while ensuring that users receive the most up-to-date versions when changes occur.

In this approach, the version number in the URL acts as a cache buster. When the asset changes, the version number is incremented, prompting the browser to fetch the new version instead of relying on the cached one. This technique is particularly useful for static assets like CSS and JavaScript files, where changes are infrequent but need to be reflected immediately when they occur.

Inspired by this, I implemented a similar versioning strategy for our analytics data. I stored a cache version number on the client, either in a cookie or local Storage:

cacheVersion = 1

Whenever the backend detected a change in the analytics data, the version number was incremented:

1. Increment version → 2

2. Update client cookie

3. New requests fetch new data

This approach worked well initially, as it ensured that users received the latest data without manually invalidating each cache entry. It simplified cache management by using a single version number to control data freshness.

Use Cases Where This Works:

• Static Assets: Ideal for assets like images, stylesheets, and scripts where changes are infrequent but need immediate reflection.

• Data with Predictable Changes: Suitable for datasets that change at known intervals or events, allowing for controlled version increments.

However, while this method was effective for a time, it eventually revealed some drawbacks, particularly in scenarios with frequent data changes or multi-device usage, where maintaining consistency became challenging.

The Problems With Client-Side Versioning: Challenges Uncovered

Here’s what I discovered very quickly about the drawbacks of using client-side versioning for cache management:

1. Multi-Device Consistency Failures

When a user accessed the dashboard from multiple devices, such as a laptop and a mobile phone, they could end up with different cache versions:

• Laptop → version 1

• Mobile → version 2

This inconsistency meant that users would see different analytics data on each device for a short period, leading to confusion and a poor user experience. This lack of synchronization across devices was not ideal for maintaining data consistency.

2. Version Storms

During periods of high activity, the analytics pipeline triggered multiple updates in rapid succession, causing a series of version increments:

• v1 → v2 → v3 → v4 → v5

Clients were upgrading to new versions at different times, which led to Redis accumulating unnecessary key clusters, such as:

• analytics:v1:summary

• analytics:v2:summary

• analytics:v3:summary

Each version bump fragmented the cache further, creating a cluttered and inefficient cache storage. This fragmentation made cache management more complex and less efficient.

3. Thundering Herd Problem

Frequent version changes resulted in all new requests missing the cache and hitting the database simultaneously. This scenario, known as the Thundering Herd Problem, occurred when

• Multiple clients experienced cache misses

• All clients recomputed the same analytics data

This led to a burst of load on the database, spiking CPU usage and potentially degrading system performance. The increased load could overwhelm the database, leading to slower response times and reduced system reliability.

These issues highlighted the limitations of client-side versioning in scenarios with frequent data changes and multi-device usage, necessitating a more robust solution for cache invalidation and management.

Better Solution Server-Side Versioned Namespaces

After several experiments, I landed on a cleaner architecture.

The Idea:

• Keep version metadata server-side, inside Redis.

• Do NOT store version on the client.

• Do NOT delete keys.

• Do NOT scan Redis.

Instead, maintain a version key per namespace:

cache:analytics:version = 7

When storing analytics data:

key = analytics:{version}:summary

When invalidating:

INCR cache:analytics:version

That's it.

This approach eliminates the need for SCAN operations, key deletions, or complex coordination. New requests automatically use the new namespace, ensuring they access the most up-to-date data. Meanwhile, old data will naturally expire through TTL, simplifying cache management and maintaining system efficiency.

Why This Works Beautifully

1. O(1) Invalidation
   By using a single atomic Redis operation like INCR cache:analytics:version, you can efficiently invalidate cache entries without the need to delete hundreds of keys. This approach significantly reduces the complexity and time required for cache invalidation, leading to improved system performance.

2. Consistency Across Devices
   Storing the version server-side ensures that all devices access the most current data simultaneously. This eliminates discrepancies across different devices, providing a consistent user experience and reducing confusion.

3. No Thundering Herd (If You Warm the Cache)
   Warming the cache is a technique where you precompute and store data in the cache before users request it. This means that when a user makes a request, the data is already available in the cache, and the system doesn't need to fetch or compute it from the database in real-time.

   Here's how it works and why it's beneficial:

   1. Precomputation: Before users access the data, the system calculates and stores the results in the cache. This is done during off-peak times or as part of a scheduled process.

   2. Immediate Availability: When a user requests the data, the system retrieves it directly from the cache, which is much faster than querying the database.

   3. Reduced Database Load: Since the data is already computed and stored in the cache, the database doesn't have to handle as many requests. This reduces the load on the database, preventing spikes in CPU usage and potential slowdowns.

   4. Improved Performance: Users experience faster response times because the data is served from the cache rather than being computed on-the-fly.

By warming the cache, systems can handle more requests efficiently, maintain stability during high traffic periods, and provide a seamless user experience.

4. Zero Tracking Needed
   Versioning automatically creates namespaces, eliminating the need to track which keys belong to which pages. This simplifies cache management and reduces the risk of errors in cache invalidation.

5. Old Keys Don’t Hurt
   Older key groups (e.g., analytics:v5, analytics:v6, analytics:v7) will naturally expire without requiring manual deletion or complex pattern matching. This reduces maintenance overhead and ensures efficient cache storage.

Real-World Examples from FAANG Companies:

Amazon

Amazon's retail platform relies heavily on caching to deliver fast and reliable user experiences. One challenge they faced was ensuring that product information and availability were always current, especially during high-traffic events like Black Friday. By implementing efficient cache invalidation strategies, Amazon can quickly update product details and stock levels without causing delays or inconsistencies. This approach helps maintain a seamless shopping experience, even under heavy load, by ensuring that customers always see the most accurate information.

Netflix

Netflix uses caching extensively to deliver streaming content efficiently. A significant challenge for Netflix is managing the vast amount of content and ensuring that recommendations and availability are up-to-date. By managing cache versions server-side, Netflix can swiftly update content availability and recommendations without disrupting the user experience. This strategy allows them to handle frequent content updates and user interactions smoothly, ensuring that viewers receive the most relevant and current content suggestions.

These examples illustrate how large-scale systems benefit from efficient cache invalidation strategies. By addressing challenges such as data freshness and system load, these companies achieve improved performance, consistency, and user satisfaction.

Architecture Diagram : Visualizing the Improved System

After transitioning to server-side versioned namespaces, we observed significant improvements

• Our dashboard's performance increased noticeably, providing faster access to data.

• Stale data issues were completely eliminated, ensuring users always received the most current information.

• We no longer needed to perform SCAN or DEL operations, simplifying our cache management process.

• Cache invalidation became predictable and instantaneous, enhancing system reliability.

• Consistency issues across different devices were resolved, offering a seamless user experience.

Ultimately, we realized that while caching accelerates systems, effective invalidation is what truly enables scalability.

Caching makes systems fast. Invalidation makes them scalable.

---

Conclusion: The Real Challenge of Caching Systems

Improving response times with Redis or HTTP caching was straightforward, but managing old data without disruption was challenging.

Client-side versioning initially seemed promising but failed with multiple devices, rapid changes, burst invalidation, and consistency needs. The true solution was server-side versioned namespaces with metadata stored in Redis. This approach is simple, scalable, easy to understand, framework-agnostic, and widely used by high-scale systems. If you're developing systems reliant on changing cached datasets, consider adding this pattern to your architectural toolkit.

If you found this helpful, please support and share!