Caching Done Right

Let’s say you are building an application that shows user profiles, product pages, or dashboards.

When your application has low traffic, every request goes directly to the database. Responses are fast, and everything feels smooth.

As the application grows, the same data is requested again and again.
The database keeps doing repeated work for identical queries. Slowly, the database becomes overloaded. Response times increase, and users start noticing delays.

If you don’t introduce caching properly, your system wastes resources and struggles under load.

In this lesson, we’ll walk through practical caching strategies, step by step, in a way that makes sense for beginners and system design interviews.

1. Cache-Aside Pattern

Cache-aside is the most common caching strategy. In this approach, the application controls the cache. When a request comes in, the application first checks the cache. If the data is found, it is returned immediately. If the data is not found, the application queries the database, stores the result in the cache, and then returns it.

Writes go directly to the database. After a write, the cache is either updated or invalidated. This pattern is simple, flexible, and widely used.

Example:
When loading a user profile, the app checks Redis first.
If the profile is missing, it fetches it from the database and caches it for future requests.

Cache-aside is usually the default choice in system design interviews.

2. Write-Through Caching

In write-through caching, all writes go through the cache.

The application writes data to the cache, and the cache immediately writes the same data to the database.

This ensures that the cache always contains the latest data.

The downside is slower write performance, since every write must update both cache and database.

Example:
A configuration service where reads must always return the latest value uses write-through caching to avoid stale data.

Write-through caching is useful when data correctness is more important than write speed.

3. Write-Behind (Write-Back) Caching

Write-behind caching delays database writes.

The application writes data to the cache first.
The cache then writes the data to the database asynchronously in the background.

This makes write operations very fast.

However, if the cache fails before data is persisted, data loss can occur.

Example:
Tracking page views or analytics counters where exact accuracy is not critical uses write-behind caching.

Write-behind caching is used carefully and only when performance matters more than durability.

4. TTLs (Time To Live)

Cached data should not live forever. A TTL defines how long a cache entry remains valid. Once the TTL expires, the data is removed automatically.

TTLs prevent stale data from staying in cache indefinitely and help manage memory usage.

Choosing the right TTL is important. Too long leads to outdated data. Too short leads to frequent cache misses.

Example:
User profiles cached for 5 minutes.
Product listings cached for 30 minutes.

TTLs are one of the simplest but most important caching tools.

5. Cache Invalidation Strategies

Cached data becomes incorrect when the underlying data changes. This problem is called cache invalidation.

There are common ways to handle it. You can delete cache entries when data is updated. You can update the cache immediately after a write. Or you can rely on TTLs to expire old data naturally.

Most real systems use a combination of these approaches. Poor cache invalidation leads to users seeing outdated or incorrect information.

6. Redis Design Patterns in Real Systems

Redis is more than a simple key-value store. It is commonly used for rate limiting. Each request increments a counter with a TTL. If the limit is exceeded, requests are blocked.

Redis is also used for session storage. User sessions are stored centrally so multiple app servers can share login state.

Another common use is leaderboards. Redis sorted sets allow fast ranking and score updates.

These patterns make Redis a core building block in many architectures.

7. Preventing Cache Stampede

A cache stampede happens when many requests miss the cache at the same time. This often occurs when a popular cache entry expires or the cache goes down.

Suddenly, all requests hit the database together, overwhelming it. To prevent this, systems use techniques such as locking during cache rebuild, refreshing cache before expiration, or temporarily serving stale data.

Preventing cache stampede is critical in high-traffic systems.

8. When Not to Use Caching

Not all data should be cached. Highly dynamic data, data that changes constantly, or data that requires strong consistency may not benefit from caching.

Caching adds complexity. If the performance benefit is small, caching may not be worth it.

Good system design includes knowing when to avoid caching.

Final Thoughts

Caching is one of the most powerful tools in system design.

When done right, it dramatically improves performance and scalability.
When done poorly, it causes bugs, stale data, and outages.

There is no single caching strategy that fits every system.
The right choice depends on data freshness, access patterns, and consistency needs.

In system design interviews, what matters most is not naming patterns, but explaining why you chose a caching approach.

If you can clearly explain the trade-offs, you are already ahead.