Caching Strategies

Shiljo Paulson
4 min readFeb 28, 2022

--

Photo by Markus Spiske on Unsplash

Improving performance in turn improves the response time which in turn improves the overall experience of the application because nobody wants to wait.

The primary intention behind caching is to improve performance while retrieving the data or resource.

Caching ensures high throughput and low latency. An application with cache will return the response in less time as opposed to an application without a cache. Here are the various strategies discussed in this blog/article

  • Cache-aside
  • Read-through
  • Write-through
  • Write back

The primary intention behind all the strategies is to reduce the round-trip time between application and database because accessing database is always an expensive operation.

Cache-aside

This is the most widely adopted strategy. So how does this strategy work?

When an application receives the request for a resource it first checks if it exists in cache & if it exists then it is called Cache Hit else it's called Cache Miss.

In the above diagram you can see that since it is a Cache Hit & it returns the results immediately from the cache. Now let’s see the second scenario

Since it is a Cache Miss it reads the data from the database & then it updates the Cache for the future requests.

Pros:

  • Best for read heavy operations (when there are frequent read requests)

Cons:

  • The first request of the resource will be slow since it is lazy loaded.
  • Not suitable for moderate/heavy write operations.
  • Data Consistency: Data in cache and database can be different at any given point of time & it all depends on TTL (Time-To-Live).

TTL is the duration for which a resource is going to be cached.

Usually Time-To-Live (TTL) is directly proportional to data inconsistency. So, the larger the TTL is more prone to have different values

Read-through

This is similar to Read-aside, but this strategy will provide data consistency as well.

Here application requests the Cache and it is the cache’s responsibility to give back results and there is not directly dealing with database by the application.

This has the same pros and cons as Cache-aside but will give more consistent data.

Write-through

Here in this strategy data will be in line with the database let’s see how?

Here write operations are performed via cache and to make it work all write operations must go via cache.

Cons:

  • For some reason if cache fails, we will lose the database update.
  • There will be a slight delay in performing the write operation in the database because it saves first in the cache.

All write operations should go via Cache which has its own Pros & Cons depending on the use case.

Usually, it is combined with read-through to have consistent data while read and write operations.

Write back

This strategy like Write-through and it is best suited for write heavy operations. Let’s see how it works.

Application sends the write operation to the cache and cache updates itself first and then it updates the database after an intentional delay. The Delay is performed to prevent multiple write operations to the database and which in turn optimizes the performance of the application overall.

If you notice in the above diagram multiple requests are received at the cache but it will perform fewer database updates.

Pros:

  • Best suited for Heavy write operations.

Cons:

  • For some reason if cache fails, we will lose the database update.
  • There will be a slight delay in performing the write operation in the database because it is first saved in cache.

To have more consistent data combine it with read-through.

Summary

Usually, a common issue with caching is data consistency. Trying to achieve data consistency introduces issues like the cons mentioned in Write-through and Write-back strategies.

The beauty of Caching is it can be implemented at multiple places of an application, thus cutting down the latency comprehensively by a significant amount.

Please let me know your valuable comments.

--

--

Shiljo Paulson
Shiljo Paulson

Written by Shiljo Paulson

System Design, Full stack Developer, good at OOPs, .Net, C#, TypeScript, JavaScript, SQL, HTML. Recent times interest is on Cloud, System Design and GoLang.

No responses yet