Database Caching Strategies

28/01/2024, 10:07 SDC#17 - Database Caching Strategies - by Saurabh Dashora
SDC#17 - Database Caching Strategies

Are microservices silver bullets? And More...
SAURABH DASHORA
5 DEC 2023
4 Share
Hello, this is Saurabh… 👋

Welcome to the 176 new subscribers who have joined us since last week.
If you aren’t subscribed yet, join 1900+ curious Software Engineers looking to expand their
system design knowledge by subscribing to this newsletter.
In this edition, I cover the following topics:
🖥 System Design Concept → Database Caching Strategies

🍔 Food For Thought → Are Microservices Silver Bullets?
So, let’s dive in.
🖥 Database Caching Strategies

Databases are critical to an application’s performance.
In fact, I think they are on top of the most important factors when it comes to
performance.
https://newsletter.systemdesigncodex.com/p/database-caching-strategies 1/13
The difference between good performance and poor performance comes down to
how well you deal with the typical database challenges such as:
Query processing speed
Cost of scaling
Making data access easy
Balancing these challenges is important to get the most out of your system.
But sometimes, you need quick results.
And that’s where Database Caching can offer you the “olive branch” you were
looking for.
What is Database Caching?

A cache is a collection of items.
You can think of a cache as a stockpile of something that you need to keep handy for
quick access in a time of need. For example, a cache of medicines or a stock of food
items.
When it comes to software engineering, the meaning isn’t so different.
Think about a bunch of bestseller products on an e-commerce website, a list of

country codes, or the most popular posts on your blog.
What do these things have in common?
Yes, they are all frequently needed by the users.
Going to the database every single time a user asks for these frequently accessed items
is a serious drag on performance.
Why not store the frequently accessed data in temporary storage that is faster than
database access?
This temporary storage location is the cache.
You can play around with the image on Eraser.io
So - how can we define Database Caching?
In essence, Database Caching is a buffering technique that stores frequently-read data in

temporary memory.
This temporary memory is optimized for high-speed data storage resulting in faster access to
the information as compared to the primary database.
Of course, database caching itself is not a singular technique.
It’s an umbrella term for a bunch of strategies that you can adopt depending on your
data.
Database Caching Strategies

If you find database caching useful and want to use it to build your next million-
dollar application, it’s important to evaluate the various strategies at your disposal.
Each strategy has a slightly different twist on the relation between the cache and the
database.
This twist can have a good deal of impact on how you end up designing your
application.
Let’s look at these strategies:
Cache-Aside Strategy
This is by far the most common strategy used in the wild.
Here’s what it looks like:
In this strategy, the cache sits next to the database.
When there is a request for data, the application first checks the cache.
If the cache has the data (i.e. a cache hit), the application will return from the
cache.
If the cache doesn’t have the data (a cache miss), the application queries the
database and returns the data to the requester.
The application also stores the missing data in the cache for any future requests.
This strategy is great for read-heavy workloads.
Also, since the cache is separate from the database, a cache failure cannot cripple the
system. The application can always go directly to the database.
That’s wonderful for resiliency.
However, the main drawback of cache-aside is the potential inconsistency between

the cache and the database. Any data being written or updated goes to the database
and therefore, the cache may have a period of inconsistency with the primary
database.
But it’s something that we can get around.
Read-Through Strategy
In the read-through strategy, the cache sits between the application and the
database.
See the below diagram:
Here’s what happens in read-through:
The application will always reach out to the cache for any read request.
If there’s a cache hit, the data is immediately returned from the cache and that’s
the end of the flow.
But in case of a cache miss, the cache will get the missing data from the database
and return it to the application.
In case you’re wondering, any write requests still go directly to the database.
So, how is read-through any different from cache-aside?
In cache-aside, the application is responsible for fetching the data and populating the
cache. In read-through, all of this is done by a library or a cache provider.
The disadvantage of read-through is also the same as cache-aside:
potential data inconsistency between the cache and the database
the need to go to the database every time a brand-new read request comes
through.
The second problem is often mitigated by “warming” the cache by issuing likely-to-
happen queries manually. You can think of it as a form of pre-caching.
Thanks for reading System Design Codex!

Subscribe for free to receive new posts and
support my work.
Write-Through Strategy
The write-through strategy tries to get around the problem with read-through.
Instead of writing data to the database, the application first writes to the cache and
the cache immediately writes to the database.
The word “immediately” is important over here.
Check the below illustration:
The advantage of write-through is that the cache is ensured to have any written data.
New read requests won’t experience a delay while the cache requests the data from
the main database.
What’s the downside?
Extra write latency because the data must go to the cache and then to the database.
While the impact should be negligible, there are still two writes happening one after
the other.
You can also combine write-through with read-through to get the good parts of the
read-through strategy without the whole data consistency issue.
Write-Back Strategy
Write-back strategy is essentially a variation of the write-through strategy.
There’s just one key difference.
In the write-back strategy, the application writes directly to the cache (just like write-
through). However, the cache does not immediately write to the database but after a
delay.
The advantage of this is that the strain on the cache is reduced in case you have a
write-heavy workload. Requests to the database are batched and the overall write
performance is improved.
The downside is that in case of a cache failure, there are chances of possible data
loss.
Write-Around Strategy
In the write-around strategy, data is always written to the database and the data that
is read goes to the cache.
In case of a cache miss, the application will read from the database and update the
cache for the next time.
Here’s what it looks like:
This is basically the same as a cache-aside or read-through strategy with the added
context around how the writes are handled.
The best use of this strategy is in cases where data is only written once (or rarely
updated) like a blog post or a static website.
👉 At this point, you may be thinking that all of these strategies sound so
confusing and it’s hard to remember
And I’m with you on the same boat on this one.
Therefore, I made a handy table that can help you check out all the above strategies
at a quick glance.
Here you go:
Thanks for reading System Design Codex!

Subscribe for free to receive new posts and
support my work.
🍔 Food For Thought

👉 Are Microservices Silver Bullets?
There’s no doubt that microservices are useful.
But there’s also no doubt that microservices have been hyped a lot over the last few
years.
I have witnessed an entire department collapsing and good folks getting fired just
because there was a blind obsession with microservices.
To make the best use of microservices, the first rule I follow is this:
“Microservices are NOT silver bullets”
I wrote a detailed post on this on X (Twitter) and got some amazing responses.
Do check it out below 👇
Here’s the link:
https://x.com/ProgressiveCod2/status/1728011683199844757?s=20
👉 How to Approach Domain-Driven Design (DDD)?

Domain-driven design has so many terms to understand that it can sometimes feel
confusing.
But ultimately, there are just two important things that you should focus on:
Focus on the core domain
Maintaining encapsulation
The below post explains this approach beautifully 👇
Here’s the link to the post:
https://x.com/Sunshine_Layer/status/1728496171834913057?s=20
That’s it for today! ☀️

Enjoyed this issue of the newsletter?
Share with your friends and colleagues.
See you later with another value-packed edition — Saurabh.
4 Likes
Comments
Write a comment...
© 2024 Saurabh Dashora ∙ Privacy ∙ Terms ∙ Collection notice

Substack is the home for great writing

Database Caching Strategies

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Database Caching Strategies

Uploaded by

Copyright:

Available Formats

28/01/2024, 10:07 SDC#17 - Database Caching Strategies - by Saurabh Dashora

SDC#17 - Database Caching Strategies

Hello, this is Saurabh… 👋

In this edition, I cover the following topics:

🖥 System Design Concept → Database Caching Strategies

🖥 Database Caching Strategies

Query processing speed

Making data access easy

But sometimes, you need quick results.

What is Database Caching?

When it comes to software engineering, the meaning isn’t so different.

Think about a bunch of bestseller products on an e-commerce website, a list of

What do these things have in common?

Yes, they are all frequently needed by the users.

This temporary storage location is the cache.

You can play around with the image on Eraser.io

So - how can we define Database Caching?

In essence, Database Caching is a buffering technique that stores frequently-read data in

Of course, database caching itself is not a singular technique.

Database Caching Strategies

Let’s look at these strategies:

Here’s what it looks like:

You can play around with the image on Eraser.io

In this strategy, the cache sits next to the database.

This strategy is great for read-heavy workloads.

That’s wonderful for resiliency.

However, the main drawback of cache-aside is the potential inconsistency between

But it’s something that we can get around.

See the below diagram:

You can play around with the image on Eraser.io

Here’s what happens in read-through:

So, how is read-through any different from cache-aside?

The disadvantage of read-through is also the same as cache-aside:

potential data inconsistency between the cache and the database

Thanks for reading System Design Codex!

The word “immediately” is important over here.

Check the below illustration:

You can play around with the image on Eraser.io

What’s the downside?

There’s just one key difference.

You can play around with the image on Eraser.io

Here’s what it looks like:

You can play around with the image on Eraser.io

And I’m with you on the same boat on this one.

Here you go:

Thanks for reading System Design Codex!

🍔 Food For Thought

“Microservices are NOT silver bullets”

Do check it out below 👇

Here’s the link:

👉 How to Approach Domain-Driven Design (DDD)?

Focus on the core domain

The below post explains this approach beautifully 👇

Here’s the link to the post:

That’s it for today! ☀️

Enjoyed this issue of the newsletter?

Share with your friends and colleagues.

See you later with another value-packed edition — Saurabh.

© 2024 Saurabh Dashora ∙ Privacy ∙ Terms ∙ Collection notice

You might also like