Caching Patterns in System Design
Caching is one of the most effective ways to improve the performance and scalability of a software system. It reduces response time, lowers database load and helps applications handle more traffic. In this article, we will discuss about caching patterns or cache strategies considering that we already know some basics of caching, cache hit/miss rate, cache eviction and invalidation.
1. Cache-aside pattern
Cache-aside, also called lazy loading, is the most commonly used caching pattern. The application communicates directly with both the cache and the database.
Read flow
1. Application checks the cache.
2. If the value exists, return it.
3. If the value is missing, read it from the database.
4. Store the value in the cache.
5. Return the value.Write flow
1. Update the database.
2. Delete the cached value.
3. Allow the next read to rebuild the cache.When to use it ?
Cache-aside is the best general-purpose default when reads greatly exceed writes and some temporary staleness is acceptable.
2. Read-through caching
In read-through caching, the application asks the cache for data. If the data is missing, the cache loads it from the database. The difference from cache-aside is responsibility:
- In cache-aside, the application loads missing data.
- In read-through, the cache layer loads missing data.
Read flow
1. Application requests data from the cache.
2. Cache checks for the value.
3. On a hit, the cache returns the value.
4. On a miss, the cache loads it from the database.
5. Cache stores and returns the value.3. Write-through caching
In write-through caching, the application writes to the cache, and the cache synchronously writes the same data to the database. The write is considered successful only after the database update succeeds.
Write flow
1. Application sends a write to the cache.
2. Cache updates the database.
3. Cache stores the updated value.
4. Success is returned to the application.When to use it ?
Data that must be immediately available after an update and systems where cache freshness is more important than write speed.
4. Write-behind caching
Write-behind caching is also called write-back caching. The application writes to the cache first. The database is updated asynchronously later.
Write flow
1. Application writes to the cache.
2. Cache immediately confirms the write.
3. A background process collects pending changes.
4. Changes are eventually written to the database.When to use it ?
Systems where temporary data loss is acceptable.
5. Write-around caching
In write-around caching, writes go directly to the database and bypass the cache.
Write flow
1. Application writes directly to the database.
2. Existing cached data is deleted or allowed to expire.
3. The next read loads the updated value into the cache.6. Refresh-ahead caching
Refresh-ahead caching updates popular cache entries shortly before they expire. Instead of waiting for a user request to discover that the value has expired, the system refreshes it proactively.
When to use it ?
For known high-traffic objects. Refresh-ahead should normally be limited to proven popular keys.
Summary
There is no single caching pattern that is best for every system. Cache-aside is usually the safest starting point. Write-through is useful when cached data must be immediately current. Write-behind provides faster writes but introduces durability risks. Write-around prevents write-heavy data from polluting the cache. Refresh-ahead help keep popular data available with predictable latency.
Get Adarsh Tyagi’s stories in your inbox
Join Medium for free to get updates from this writer.
The most important caching question is not:
Which caching technology should we use?
It is:
How does the data become stale, how will it be refreshed, and what happens when the entire cache disappears?
A strong caching design explains performance, consistency, invalidation, failures and business correctness — not just where Redis/Memcache is placed in the architecture.
