19. System Design: Distributed Cache and Caching Strategies | Cache-Aside, Write-Through, Write-Back
Вставка
- Опубліковано 28 чер 2024
- ➡️ Notes: Shared in the Member Community Post (If you are Member of this channel, then pls check the Member community post, i have shared the Notes link there)
➡️ Join this channel to get access to member only perks:
/ @conceptandcoding
Topics i have covered:
- What is Cache, when to use?
- How Distribute Caching works?
- Caching Strategies and its Pros and Cons
(Cache Aside, Read Through, Write Around, Write Through and Write Back Cache)
Chapters:
00:00 - Introduction
00:53 - What is Caching
05:31 - What is Distributed Caching
10:33 - Cache-Aside Caching Strategy
18:44 - Read Through Caching Strategy
22:34 - Write Around Caching Strategy
27:06 - Write Through Caching Strategy
31:48 - Write Back Caching Strategy
Consistent Hashing Video: • 6. Consistent Hashing ...
Other Playlist:
HLD: • High Level Design from...
LLD : • Low Level Design from ...
JAVA: • JAVA from Basics to Ad...
You can also connect with me 1:1 on Topmate:
topmate.io/concept_coding
Join this channel to get access to perks:
/ @conceptandcoding
#caching #systemdesign #Redis
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
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
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?
Very useful video..... indeed is one of the best i have ever seen
Thank you
Thanks Shreyansh Sir, Loved It.....
Thank you
Bahut Sahi Shreyansh.....Good Job
Thank you
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.
Can you please make video to implment caching technique in distributed system.
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.
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
Thank you @Shrayansh Jain
Thank you
Could you please share, or link the video that contains Part 2, cache eviction policies
i have not covered it yet
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.
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.
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.
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.
Buddy which software u have used in this for teaching ??
one note and wacom tab
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.
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.
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