There is a point in every system’s growth where adding more servers stops being enough.

You scale horizontally. You introduce load balancers. You distribute traffic efficiently. And yet, something still feels off.

Requests are slower than expected. Databases are under constant pressure. Systems that should scale effortlessly begin to struggle under repeated work.

And then you realise something fundamental:

The system is doing the same work again and again.

The same queries.
The same computations.
The same responses.

Over and over.

This is not a scaling problem.

It is a redundancy problem.

And the solution to this problem is one of the most powerful ideas in system design:

Caching.

What Is Caching, Really?

At a surface level, caching is often defined as storing frequently accessed data in a faster storage layer so it can be retrieved quickly.

But this definition, while correct, does not capture its true significance.

Caching is not just a performance optimisation.

It is a shift in how systems think about work.

Instead of asking:

Can we compute this quickly?

Caching asks:

Do we need to compute this at all?

That shift from computation to reuse is what makes caching so powerful.

The Cost of Repeated Work

To understand why caching matters, we need to look at what happens without it.

Imagine a system where every user request requires:

• Fetching data from a database
• Performing business logic
• Formatting a response

This process may take only a few milliseconds per request. But at scale, those milliseconds add up.

When thousands or millions of users request the same data, the system is forced to:

• Execute identical database queries repeatedly
• Perform the same computations
• Generate the same responses

This creates unnecessary load on the system, especially on components like databases, which are often the most expensive and limited resources.

Over time, this repeated work becomes the bottleneck.

Caching addresses this by eliminating redundant effort.

The Core Idea - Store Once, Serve Many

At its heart, caching is simple.

When a request is processed, instead of discarding the result, the system stores it in a cache. The next time the same request arrives, the system can return the cached result instead of recomputing it.

This introduces two fundamental concepts:

• Cache Hit - The data is found in the cache and returned immediately
• Cache Miss - The data is not in the cache, so it must be computed and then stored

The effectiveness of a caching system is often measured by its cache hit rate.

Higher hit rate → fewer expensive operations → better performance.

Why Caching Changes Everything

Caching has a profound impact on system behaviour.

Reduced Latency

Fetching data from memory is significantly faster than querying a database or calling an external service.

Increased Throughput

By reducing the load on core systems, caching allows more requests to be handled simultaneously.

Lower System Load

Databases, APIs, and backend services experience less pressure, improving overall system stability.

Better Scalability

Systems can handle larger traffic without proportionally increasing infrastructure.

This is why caching is used extensively in large-scale systems.

Platforms like Netflix and Google rely heavily on caching at multiple layers to serve massive amounts of data efficiently.

Where Does the Cache Live?

One of the most important design decisions in caching is where to place the cache.

Because caching is not a single layer, it can exist at multiple points in the system.

Application-Level Cache

The simplest form of caching happens within the application itself.

Data is stored in memory inside the server process.

This is:

• Extremely fast
• Easy to implement

But it has limitations:

• Not shared across servers
• Lost when the server restarts

This works well for small-scale systems or single-node setups.

Distributed Cache

As systems scale horizontally, caching must also scale.

Instead of storing cache locally, systems use distributed caching systems that are shared across multiple servers.

This allows:

• Consistent access to cached data
• Better cache utilisation
• Scalability across nodes

However, it introduces:

• Network overhead
• Cache synchronisation challenges

Edge Cache (CDN)

At the highest level, caching can move closer to the user.

Content Delivery Networks (CDNs) store cached data in geographically distributed locations.

When a user requests content, it is served from the nearest location rather than the origin server.

This drastically reduces latency and server load.

This is how platforms like Amazon and Netflix deliver content globally with high performance.

The Trade-off Begins

At this point, caching may seem like a perfect solution.

Faster responses.
Lower load.
Better scalability.

So why not cache everything?

Because caching introduces a new and unavoidable challenge:

Data can become stale.

When the underlying data changes, cached data may no longer be accurate.

And this leads us to one of the hardest problems in system design:

Cache invalidation.

But as systems grow, a deeper and more uncomfortable truth begins to emerge:

Caching is easy to add… but very hard to get right.

Because the moment you introduce a cache, you are no longer just optimising performance, you are managing two versions of reality:

• The source of truth (database)
• The cached copy (fast, but potentially outdated)

And keeping these two in sync is where the real challenge begins.

Cache Invalidation - The Hardest Problem

There’s a well-known saying in system design:

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

It sounds like a joke, but it isn’t.

Cache invalidation is the process of ensuring that cached data remains accurate when the underlying data changes.

Let’s say a product’s price changes in the database. If the old price is still stored in the cache, users may see outdated information.

So the system must decide:

• When should the cache be updated?
• Should it be updated immediately or later?
• Should it be removed entirely?

Each choice comes with trade-offs between consistency, performance, and complexity.

Common Approaches to Cache Invalidation

There is no single correct way to handle cache invalidation. Instead, systems use different strategies depending on their requirements.

Time-Based Expiration (TTL)

One of the simplest approaches is to assign a time-to-live (TTL) to cached data.

After a fixed duration, the cache entry expires and is removed.

This approach is:

• Easy to implement
• Predictable
• Widely used

But it has limitations.

If the TTL is too long:

• Data may remain stale for too long

If the TTL is too short:

• Cache effectiveness decreases (more misses)

So choosing the right TTL becomes a balancing act.

Write-Based Invalidation

Another approach is to update or invalidate the cache whenever data changes.

For example:

• When a product is updated → update or delete its cache entry

This ensures better consistency, but introduces complexity:

• Every write operation must handle cache updates
• Failures in cache updates can lead to inconsistencies

This approach works well when accuracy is critical.

Explicit Invalidation

Sometimes, systems explicitly remove cache entries when they know data has changed.

Instead of updating the cache, they simply delete it, forcing the next request to fetch fresh data.

This is simple and safe, but may temporarily increase load due to cache misses.

Caching Strategies - When to Read and Write

Beyond invalidation, another important question is:

When should the system interact with the cache?

This leads to different caching strategies.

Cache-Aside (Lazy Loading)

This is the most commonly used strategy.

When a request arrives:

1. Check the cache
2. If data exists → return it (cache hit)
3. If not → fetch from database, store in cache, then return

This approach is:

• Simple
• Flexible
• Widely adopted

But it can lead to stale data if not invalidated properly.

Write-Through Cache

In this strategy, data is written to both:

• Cache
• Database

simultaneously.

This ensures that the cache is always up-to-date.

However:

• Writing becomes slower
• More coordination is required

Write-Back (Write-Behind)

Here, data is first written to the cache, and the database is updated later.

This improves write performance but introduces risk:

• If the cache fails before writing to the database, data may be lost

This strategy is used when performance is prioritised over immediate consistency.

Cache Eviction - Making Space for New Data

Caches are not infinite.

At some point, they run out of space.

So the system must decide:

Which data should be removed to make room for new data?

This is handled through eviction policies.

LRU (Least Recently Used)

Removes data that has not been accessed recently.

This works well because frequently accessed data tends to remain in the cache.

LFU (Least Frequently Used)

Removes data that is accessed the least often.

This is useful when certain data is consistently popular.

TTL-Based Eviction

Data is removed after a fixed time, regardless of usage.

Each policy reflects a different assumption about how users interact with data.

Choosing the right one depends on your access patterns.

When Caching Goes Wrong

Caching is powerful, but when misused, it can create serious problems.

Stale Data Issues

Users see outdated information, leading to inconsistencies.

Cache Stampede

When a popular cache entry expires, many requests hit the database simultaneously, overwhelming it.

Increased Complexity

Managing cache logic, invalidation, and consistency adds significant engineering overhead.

Hidden Bugs

Caching can mask underlying issues, making debugging harder.

The Deeper Insight

At this point, caching should no longer feel like a simple optimisation.

It is a trade-off system.

You trade:

• Freshness for speed
• Simplicity for performance
• Consistency for scalability

And like everything in system design, there is no perfect choice.

Only the choice that best fits your requirements.

Final Thought

The most important thing to understand about caching is this:

Caching does not make your system faster; it makes your system do less work.

And at scale, doing less work is the only way to survive.

Because the systems that scale are not the ones that compute faster:

They are the ones that avoid unnecessary computation altogether.