Skip to main content

Caching strategies

Caching Strategies

One of the easiest and most popular ways to increase system performance is to use caching. When we introduce caching, we automatically duplicate our data. It's very important to keep your cache and data source in sync (more or less, depends on the requirements of your system) whenever changes occur in the system.
In this article, we will go through the most common cache synchronization strategies, their advantages, and disadvantages, and also popular use cases.


Based on my experience, this one is perhaps the most commonly used caching strategy. The idea is that the cache sits on the side and the application talks to both the cache and the data source. The application logic inspects the cache before hitting the data source.

Aside-Cache Diagram
Here's what's happening on request:
  1. The application determines whether the item is currently held in the cache.
  2. If the item is in the cache it's called cache hit. The item is read from the cache and returned to the client.
  3. If the item is NOT found in the cache it's called cache miss. The application reads the item from the data store, stores a copy of the item in the cache, and returns it back to the client.

Use Cases

A cache-aside strategy is usually a general purpose and works best for read-heavy workloads.


  1. Systems using cache-aside strategy are resilient to cache failures. If the cache goes down, the system can still operate by going directly to the data source.


  1. Implementing the cache-aside pattern doesn't guarantee consistency between the data store and the cache. Do guarantee this we need to use other strategies to update or invalidate caches. 
  2. When the data is requested the first time, it always results in the cache miss and requires the extra time of loading data the cache. To deal with this developers use 'warming' or 'pre-heating' the cache by issuing queries manually.


Instead of managing both the data source and the cache, we can simply delegate the data source synchronization to the cache provider. All data interaction is done through the cache abstraction layer.
Both cache-aside and read-through load data lazily only on the first read.

Read-Through Diagram

Use Cases

Read-through caches work best for read-heavy workloads when the same data is requested many times.
It's very similar to cache-aside strategy, but there is difference:
In cache-aside, the application is responsible for fetching data from the data store and populating the cache. In read-through, this logic is supported by the library or cache provider.


  1. Decrease load on the data source when there are a lot of reads, because cache provider can sync access to cache keys, so in the end we will have only one cache miss.
  2. Systems using read-through strategy can also be resilient to cache failures. If the cache goes down, the cache provider can still operate by going directly to the data source.


  1. When the data is requested the first time, it always results in the cache miss and requires the extra time of loading data the cache. To deal with this developers use 'warming' or 'pre-heating' the cache by issuing queries manually.
  2. Just like cache-aside, data can also become inconsistent between cache and the data source.


Analogous to the read-through data fetching strategy, the cache provider can update the underlying data source every and cache entry on update request. The cache sits in-line with the data source and writes always go through the cache to the data source (or vice versa).

Write-Through Diagram

Use Cases

On its own, write-through doesn't seem to do much. In fact, it introduces extra write latency because data is written to the cache and to the data source. But when paired with the read-through, we get all the benefits of read-through and we also get data consistency guarantee, freeing us from using cache invalidation techniques.


  1. Advanced data consistency guarantee.


  1. Increased write latency.


If strong consistency is not mandated, we can simply enqueue the cache changes and periodically flush them to the data store.

Write-Behind Diagram

Use Cases

Write-behind improves the write performance and is good for write-heavy workloads. When combined with read-through, it works well for mixed workloads, where the most recently updated and accessed data is always in cache.


  1. It's resilient to data source failures and can tolerate some data source downtime.
  2. If batching or coalescing is supported, it can reduce overall writes to the data source, which decreases the load and reduces costs.


  1. If there's a cache failure, the data may be lost permanently.

Some developers use Redis for both cache-aside and write-back to better absorb spikes during peak load. And also most relational databases storage engines (i.e. InnoDB) have write-back cache enabled by default in their internals. Queries are first written to memory and eventually flushed to the disk.


Popular posts from this blog

Starting with Docker and ASP.NET Core

I love the .NET world. But for me, it always felt strange that you can run your code only inside Windows ecosystem. But now, with .NET Core, you can develop and run .NET application on Linux. Now you can use all the benefits of the Linux platform. One of such benefits is the ability to use Docker natively.

Now all major cloud services offer direct Docker containers deploy. It means you shouldn't worry about dependencies and software versions - everything is inside your container. That's why I decided to learn about Docker and share it with you here.

In this tutorial, you will learn what are ASP.NET Core and Docker, and how to use them together.
ASP.NET Core What is ASP.NET Core? Microsoft defines ASP.NET Core as:
ASP.NET Core is a cross-platform, high-performance, open-source framework for building modern, cloud-based, Internet-connected applications. What about .NET Core?  NET  Core is a framework that supports ASP.NET. It is a cross-platform, open-source re-implementation …

Fundamentals of Testing for Programmers

Testing is an important part of a software development. Testing is tightly coupled with development and many teams include not only developers but also testers (or even whole testing department). Because of this tight coupling, it is nice when testers and developers can share a common dictionary. With this goal, I'm posting here my notes on this topic.

In this post, I will try to highlight what is testing, how it's connected with quality assurance and quality management. And also will describe seven testing principles and will path you through a fundamental test process.

How to Build TypeScript App and Deploy it on GitHub Pages

Quick Summary In this post, I will show you how to easily build and deploy a simple TicksToDate time web app like this: