I think the latency values mentioned in the Redis caching strategies table need a review.
For both Cache Aside and Read Through, the table mentions “Low latency on cache miss”, which is not correct. A cache miss requires fetching data from the database, so the latency is typically higher on a cache miss and lower on a cache hit.
A more accurate description would be:
* Cache Hit: Low read latency
* Cache Miss: High/Moderate read latency (due to database access)
Could you please verify and update the table accordingly?
Great explanation. However, write around is not even a caching strategy independently, it has to be combined with read cache strategy to include cache. Else, it is just DB update logic. Right?
Great article. Please also explain what happens to write through strategy if writing to cache succeeds and writing to database fails? In this case, after ttl, the actual data would be lost.
I would follow a strategy where I would write to the database first and if it is successful, write it to cache. Even if writing to cache fails, after ttl, read aside will take care of getting the latest data available from the database.
Good read
Nice one sir, Keep posting.
Good!
Hi,
I think the latency values mentioned in the Redis caching strategies table need a review.
For both Cache Aside and Read Through, the table mentions “Low latency on cache miss”, which is not correct. A cache miss requires fetching data from the database, so the latency is typically higher on a cache miss and lower on a cache hit.
A more accurate description would be:
* Cache Hit: Low read latency
* Cache Miss: High/Moderate read latency (due to database access)
Could you please verify and update the table accordingly?
Great Explanation Ashish!
have one question, As mentioned in the Write back strategy, we don't require cache invalidation of cache entries.
but If we don't invalidate the cache then won't it keep growing?
After some point of time, shouldn't we remove the data from cache that is less frequently used and successfully committed to DB?
Great explanation. However, write around is not even a caching strategy independently, it has to be combined with read cache strategy to include cache. Else, it is just DB update logic. Right?
Well explained thank you
Great article. Please also explain what happens to write through strategy if writing to cache succeeds and writing to database fails? In this case, after ttl, the actual data would be lost.
I would follow a strategy where I would write to the database first and if it is successful, write it to cache. Even if writing to cache fails, after ttl, read aside will take care of getting the latest data available from the database.
Sorry I meant write around. Not write through
hey, for the write around strategy we only write to the database. Cache is updated during the read time similar to Cache Aside strategy