A much needed concept. Thanks for this lesson. Sir please bring the part 2 quickly. And also how can we relate redis here. If you could explain a usecase with redis server.
Hi Shreyansh, Thank u for the wonderful video and the contributions u made so far. One question related to the second part of this video or when the Cache Eviction Policy video will be out? OR am I missing something here?
Hi Shreyans, Thanks for the Lecture learnt a lot, Can u plz share the link to the Notes? I tried finding in Community but I see only spring boot and java notes there.
Hi Shreyansh, Does the "write around" strategy effectively solve the consistency problem? Imagine this scenario: at T1, thread-A reads a record from the database. At T2, thread-B writes the latest value of that record to the database. Subsequently, at T3, thread-B invalidates the cache, signaling that the record is no longer valid. However, at T4, thread-A updates the cache with the stale value it read at T1. This raises concerns about the efficacy of the "write around" approach in ensuring consistency. Despite the cache invalidation at T3, the update at T4 reintroduces a stale value, potentially leading to data inconsistencies. Let me know your thoughts around this.
Read through cache - Cache Server sits in front of the DB and fetches data from DB and updates the cache in case of Miss. Cache Library would mean its the application server that's interacting with the DB
Hi Shreyansh, What if in write back strategy db rollbacks due to some inconsistency in data then in this case cache will have ambiguous data and write operation will actually never happen.
Hey Shreyansh… in write around if a put/ patch request invalidate the data and same time db goes down and then get request comes so what is the use of this stale data ?
This stale data is of no use, it will be removed from the cache after its TTL. But in real world scenario, if DB goes down, again the read should be success from the replicas. Now this open ups one more scenario, lets understand that: - Put request has make the Cache Invalidate and updated the DB with Version 2 - Before the Sync up happens between other replicas, lets say DB got down - Read is coming, and it will read the data from DB (since mail DB is down, so replica will fulfill the request and since sync up was not happened, lets say replica has Version 1) So GET call should not put this Version1 in the Cache. Else we will put stale data in the cache. So that scenario need to be handled too. Only read it but in cache we should not put in that scenario.
Hi Shreyansh! Just one question - In Write Around Cache we are marking the entry in cache as dirty if it is updated on DB. Do we also need a 2 phase commit in this case as in Write Through Cache? Because updating the value as dirty in cache is a necessary operation to be completed along with DB update.
In write through cache we write everything in cache and the DB in a 2phase commit, meaning cache has all data that DB has. Then the cache would be heavy as well, the searchability will take more time ! Is it good only for small data scenarios? Also what's the significance of a cache if the DB and cache have same amount of data? Correct me if I am wrong but Does the presence of cache in memory and giving faster access the only pro?
Access to cache is fast compared to DB. Generally it's a happy scenario that Cache and DB has the same data but sometimes Cache helps to achieve fault tolerant when DB is down. Cache is not as big as DB bcoz the TTL of cache is less 3hrs, 10hrs etc depends upon the need. Cache searching done based on Key, so fetching the data is faster only.
As he correctly explained the older data will be removed, and new data will be added to cache using LRU, LFU or FIFO logics. So cache will not grow as big as db. It depends on the TAT and TTL. Thanks for the question it will help others get the answer.
Cache-Aside Caching Strategy Data first read from cache. If present, returned immediately. If not, its fetched from DB, updates the cache and returns Pros - Control over what gets cached. Cons - Data inconsistency issues. Complexity at application layer Read Through Caching Strategy Data is read from cache. If present, returned immediately. If not, its fetched from DB by the cache server itself, updated in cache and returned Pros - Simple Cons - Less control over what gets cached Write Around Caching Strategy Data is written to the DB. Its updated in the cache, only when read operation is performed Pros - Less data inconsistency issues Cons - Cache misses since its not always updated Write Through Caching Strategy Data is written to the DB and cache in same transaction making sure Cache is always consistent with the DB Pros - Always consistent data Cons - High latency Write Back Caching Strategy Data is written to Cache and read from Cache. Its updated in DB asynchronously using a queue/scheduler Pros - Low latency Cons - Chances of data loss
Hi Shreyansh , very useful video . But can you share the sequence diagram for all the 5 caching strategies as it will help to revise whenever needed only by seeing the sequence diagrams 😀
Yes i have shared it on LinkedIn too, i will upload on gitlab and share the link by today buddy. Thanks for reminding, i forgot to push the diagram on gitlab
How is Write back Cache fault tolerant, a) what if there is down time in messaging service where server can't push the message to queue? b) What if the server crashes before sending the status to queue while it has already sent a successfull response.
In distributed systems, we will be having multiple instances of the application running on different servers. So in order for the systems to be highly available you can go for multi node architecture.
It's not like that Shubham, we have to collect more requirements like how much get call we expect?, how much write call we expect? is there a case where same data can be requested? Is less Latency required? When DB goes down, still read and write should work? Then we can choose any strategy
hi, alok i highly encouraged everyone to make self made notes. That way, new doubts or question will come, which helps to understand the topic in much better way. but feedback taken, will improve the handwriting in all future notes.
Amazing explanation. Keep up the good work.
HI brother. I cannot appreciate the videos enough.
From last two days I am binge watching.
Please upload more videos on designing the system.
Sure i will
Sir,Have you made part2 video, or is it missing.
Thankyou for the content
Hi Shreyansh ,
Part 2 is missing in playlist …
Very well explained.......awsome!!!
A much needed concept. Thanks for this lesson. Sir please bring the part 2 quickly. And also how can we relate redis here. If you could explain a usecase with redis server.
Sure , redis is a distributed Cache only, so all which i explained is applicable to redis also
Bahut Sahi Shreyansh.....Good Job
Thank you
Very useful video..... indeed is one of the best i have ever seen
Thank you
Could you please share, or link the video that contains Part 2, cache eviction policies
i have not covered it yet
Thanks Shreyansh Sir, Loved It.....
Thank you
Hi Shreyansh, Thank u for the wonderful video and the contributions u made so far. One question related to the second part of this video or when the Cache Eviction Policy video will be out? OR am I missing something here?
where is caching part 2??
Hi Shreyans, Thanks for the Lecture learnt a lot, Can u plz share the link to the Notes? I tried finding in Community but I see only spring boot and java notes there.
Hi Shreyansh, Does the "write around" strategy effectively solve the consistency problem? Imagine this scenario: at T1, thread-A reads a record from the database. At T2, thread-B writes the latest value of that record to the database. Subsequently, at T3, thread-B invalidates the cache, signaling that the record is no longer valid. However, at T4, thread-A updates the cache with the stale value it read at T1.
This raises concerns about the efficacy of the "write around" approach in ensuring consistency. Despite the cache invalidation at T3, the update at T4 reintroduces a stale value, potentially leading to data inconsistencies. Let me know your thoughts around this.
Read through cache - Cache Server sits in front of the DB and fetches data from DB and updates the cache in case of Miss.
Cache Library would mean its the application server that's interacting with the DB
Hi, please upload part 2
Hi Shreyansh,
What if in write back strategy db rollbacks due to some inconsistency in data then in this case cache will have ambiguous data and write operation will actually never happen.
Can you please make video to implment caching technique in distributed system.
Thanks. very informative. One question. should'nt cache take responsibility for updating database in write-through strategy?
Depends, if cache library do not support this, even application can write into DB after writing into the cache
@@ConceptandCoding makes sense. In that case we need to take care is of rollbacking cache updations if DB related exception occurs. Thanks a lot.
@@vikasjoshi8381 exactly.
Hey Shreyansh… in write around if a put/ patch request invalidate the data and same time db goes down and then get request comes so what is the use of this stale data ?
This stale data is of no use, it will be removed from the cache after its TTL.
But in real world scenario, if DB goes down, again the read should be success from the replicas.
Now this open ups one more scenario, lets understand that:
- Put request has make the Cache Invalidate and updated the DB with Version 2
- Before the Sync up happens between other replicas, lets say DB got down
- Read is coming, and it will read the data from DB (since mail DB is down, so replica will fulfill the request and since sync up was not happened, lets say replica has Version 1)
So GET call should not put this Version1 in the Cache. Else we will put stale data in the cache. So that scenario need to be handled too.
Only read it but in cache we should not put in that scenario.
@@ConceptandCoding thanks for explanation. highly appreciate your service for the community. keep it up man.
Can anyone explain clearly why we can have different DS in cache aside while not in read through cache ? Unable to understand Shrayansh's explanation.
Buddy which software u have used in this for teaching ??
one note and wacom tab
Hi Shreyansh! Just one question - In Write Around Cache we are marking the entry in cache as dirty if it is updated on DB. Do we also need a 2 phase commit in this case as in Write Through Cache? Because updating the value as dirty in cache is a necessary operation to be completed along with DB update.
In write through cache we write everything in cache and the DB in a 2phase commit, meaning cache has all data that DB has.
Then the cache would be heavy as well, the searchability will take more time !
Is it good only for small data scenarios?
Also what's the significance of a cache if the DB and cache have same amount of data?
Correct me if I am wrong but Does the presence of cache in memory and giving faster access the only pro?
Access to cache is fast compared to DB.
Generally it's a happy scenario that Cache and DB has the same data but sometimes Cache helps to achieve fault tolerant when DB is down.
Cache is not as big as DB bcoz the TTL of cache is less 3hrs, 10hrs etc depends upon the need.
Cache searching done based on Key, so fetching the data is faster only.
As he correctly explained the older data will be removed, and new data will be added to cache using LRU, LFU or FIFO logics. So cache will not grow as big as db. It depends on the TAT and TTL. Thanks for the question it will help others get the answer.
Cache-Aside Caching Strategy
Data first read from cache. If present, returned immediately. If not, its fetched from DB, updates the cache and returns
Pros - Control over what gets cached.
Cons - Data inconsistency issues. Complexity at application layer
Read Through Caching Strategy
Data is read from cache. If present, returned immediately. If not, its fetched from DB by the cache server itself, updated in cache and returned
Pros - Simple
Cons - Less control over what gets cached
Write Around Caching Strategy
Data is written to the DB. Its updated in the cache, only when read operation is performed
Pros - Less data inconsistency issues
Cons - Cache misses since its not always updated
Write Through Caching Strategy
Data is written to the DB and cache in same transaction making sure Cache is always consistent with the DB
Pros - Always consistent data
Cons - High latency
Write Back Caching Strategy
Data is written to Cache and read from Cache. Its updated in DB asynchronously using a queue/scheduler
Pros - Low latency
Cons - Chances of data loss
Thank you @Shrayansh Jain
Thank you
Hi Shreyansh , very useful video . But can you share the sequence diagram for all the 5 caching strategies as it will help to revise whenever needed only by seeing the sequence diagrams 😀
Yes i have shared it on LinkedIn too, i will upload on gitlab and share the link by today buddy.
Thanks for reminding, i forgot to push the diagram on gitlab
Bhut acha video tha theory samaj m aagya but sir isko practical me kaise select krenge aur kya kya krna pdega uska bhi detail btae
I have shared the pros and cons right. That will help you to select which strategy to use.
How is Write back Cache fault tolerant,
a) what if there is down time in messaging service where server can't push the message to queue?
b) What if the server crashes before sending the status to queue while it has already sent a successfull response.
In distributed systems, we will be having multiple instances of the application running on different servers. So in order for the systems to be highly available you can go for multi node architecture.
Sir please provide notes .
distribute cache need to explain more
Sir from where u learnt all these ?
8 saal ka exp hogaya hai, kaafi to projects mein implement karne ke liye analysis karein hue hai.
👍👍
which type of cache we can use in a multiplayer game where user answer the question and they earn coins and user scale is very large ?
It's not like that Shubham, we have to collect more requirements like how much get call we expect?, how much write call we expect? is there a case where same data can be requested?
Is less Latency required? When DB goes down, still read and write should work?
Then we can choose any strategy
You're mixing TTL with TAT
Bhai notes thora sahi se bana diya karo. Kafi ghatiya handwriting rahti hai. Baad mein padhne pe samajh nahi aata ki kya likha hai
hi, alok i highly encouraged everyone to make self made notes.
That way, new doubts or question will come, which helps to understand the topic in much better way.
but feedback taken, will improve the handwriting in all future notes.
You have unnecessarily extend this video to 37 minutes. this could have been explained in 5 minutes. waste of time.