0% completed
Cache-Aside vs Read-Through, Write-Through vs Write-Back
A team puts a cache in front of its database. In the design review, someone asks two questions. On a read, what happens when the data is not in the cache? On a write, when does the change reach the database?
These are two separate decisions. This lesson explains the common strategies for each one, what each strategy costs, and how to keep the cache and the database from disagreeing.
Two Separate Decisions
There are three common read strategies:
- Cache-aside
- Read-through
- Read-around
And there are three common write strategies:
- Write-through
.....
.....
.....
kate powler
· 8 months ago
Remember, the database doesn't directly interact with the cache (unlike the diagram suggests). The application orchestrates their synchronization
asif malek
· 2 years ago
In write thru cache, we write data in db and cache at same time. What if cache write is a success and db write fails, then system will serve wrong data via cache.
Wonee
· 2 years ago
Doesn't the application interact with the DB as well? Isn't there 2 writes for a cache-through strategy?
Marko Urh
· 2 years ago
I'm thinking about write-through cache:
Data Consistency: Provides strong consistency between the cache and the primary storage. No Data Loss on Crash: Since data is written to the primary storage, there’s no risk of data loss if the cache fails.
What if cache write fails, ok we have DB, maybe we can fill cache-miss, but what if DB fails. I have a problem now. I need to ensure atomicity of this parallel operation. To achieve transaction on two separate systems something like Two phase commit, it would be useful to maybe add some more sugar to this.If there's no mechanism like that successful cache write could be serving wrong data, while DB is trying to be written or ultimately fails, but then needs to rollback cache. Unless we ensure some transaction across these two with "simul
Reading Progress
0%