0% completed
Cache-Aside vs Read-Through, Write-Through vs Write-Back
You put a cache in front of the database, and the design review 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?
Those are two separate decisions, and you answer them separately. The read strategies are cache-aside, read-through, and read-around. The write strategies are write-through, write-back, and write-around.
The lesson title pairs read-through against write-through, and that pairing misleads. They are not rivals
.....
.....
.....
kate powler
· 6 months ago
Remember, the database doesn't directly interact with the cache (unlike the diagram suggests). The application orchestrates their synchronization
asif malek
· a year 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
· a year 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%