I am ex-Google and feel like I've studied content from every popular creator out there. I feel this is clearly among the best system design content out there. You helped me earn a number of offers ranging from pre-seed startups to FAANG, including a spectacular offer for L6 TL at Amazon! I'm regularly shocked by the gap in quality from your content compared to everything else. Your communication style is concise, clear, and deeply technical. I literally watch your videos on repeat. Thank you so much for taking the time to contribute your experience back to the tech community. Keep ramming, gigachads.
Hi Jordan - Thanks for the content. Without 2PC - write through cache could have same issues as write back cache w.r.t data inconsistencies. The probability for that might me lower in write through though.
Absolutely! I think the consistency issues are still there, but write back you explicitly wait a while to batch writes, and so you're really embracing the cache being ahead of the DB.
Wondering in the write through cache why can’t we first perform the write on the db before on updating the cache, this way if the write to DB fails there’s no need to update the cache. Is this to avoid latency in the sense when you write through cache you update the cache and don’t wait for the write response from the db? But this would classify the cache as write back as well, wouldn’t?
Yeah like I mentioned there's a few variants of each. I guess write through caching the way that you proposed it could just be considered as write around caching, with an asynchronous cache loading step lol Really just depends if we need these steps to be synchronous or asynchronous
Hey Jordan, I am not sure I understood the usage of distributed lock here. so lets say client1 writes value 10 to cache and grabs a distributed lock for that entry by talking to the locking service then when client 2 reads it from DB it knows it first needs to grab the lock so it goes the locking service, locking service notifies client1 , client1 updates the cache and release the lock and then client2 call is completed.Is my understanding right? If it is that means both client1 and client2 knows in advance they need to grab the lock before writing/reading values?
I noticed that in the video, you mentioned phrases like 'the cache asks the database for the value' or 'the cache updates the database.' My understanding, though, is that there isn't a direct connection between the cache and the database. Instead, it’s the application that detects a cache miss, fetches the value from the database, and then updates the cache. Could you clarify this part? Thanks!
Hey just asking but do you think you'll get into ml systems design? If not can you sort of describe your process for learning what you present on the channel, i.e. starting with DDIA, then looking at the documentation for databases, etc so I can try to do the same if I ever go down that route. Also I believe you mentioned you switched from tech to finance, do you have to set up ml systems there?
Very little ML in my role in particular, and to be honest my company just isn't that into it it's not super practical in HFT but companies are starting to try to apply it more. I think you basically just named my learning process haha. I was looking into vector databases the other day to see if they're worth talking about, and as of now the answer is maybe ;). It's a lot of math
hey Jordan great video (when did you not have one), so for the write-around we are delegating the cache update to the read request? So on the cache miss during the read, we want to update the cache with the data from DB? Or am I missing something?
Yes, that's the whole point. When you are there to read the data and the cache miss occurs, what choice do you have? You can only get data from the database. Then you return that data over to the user and save this data in the cache for the next requests.
Hello Jordan, Regarding the distributed lock, Does the cache grabs the lock till the data is eventually written into DB? And will this be transaction specific lock or can be shared when multiple client updates the data in cache?
I am wondering if the read / write cache are usually the same one cache in system? And if read cache has pattern like read-through, read-around, and read-back as well?
Unless you're doing single leader replication with your caches, you'd be able to write to any. As for your second question, these are not policies I've heard of
I am ex-Google and feel like I've studied content from every popular creator out there. I feel this is clearly among the best system design content out there. You helped me earn a number of offers ranging from pre-seed startups to FAANG, including a spectacular offer for L6 TL at Amazon!
I'm regularly shocked by the gap in quality from your content compared to everything else. Your communication style is concise, clear, and deeply technical. I literally watch your videos on repeat. Thank you so much for taking the time to contribute your experience back to the tech community.
Keep ramming, gigachads.
Really appreciate the kind words! Best of luck in your new role, well done!!
The way you throw random jokes and your super clear explanation makes consuming your content a piece of cake. Keep up the great work.
Thanks Ricardo!
your silly jokes remind me of how I was when I was your age, never change dude. Work harder to keep this energy.
Haha oh man if I work any harder for that I may lose my job
Hi Jordan - Thanks for the content. Without 2PC - write through cache could have same issues as write back cache w.r.t data inconsistencies. The probability for that might me lower in write through though.
Absolutely! I think the consistency issues are still there, but write back you explicitly wait a while to batch writes, and so you're really embracing the cache being ahead of the DB.
Wondering in the write through cache why can’t we first perform the write on the db before on updating the cache, this way if the write to DB fails there’s no need to update the cache. Is this to avoid latency in the sense when you write through cache you update the cache and don’t wait for the write response from the db? But this would classify the cache as write back as well, wouldn’t?
Yeah like I mentioned there's a few variants of each. I guess write through caching the way that you proposed it could just be considered as write around caching, with an asynchronous cache loading step lol
Really just depends if we need these steps to be synchronous or asynchronous
What is YOLO?
"yo only live once"
Aka no replication and hope your things don't break
@@jordanhasnolife5163 aka the optimistic anxiety control
Hey Jordan, I am not sure I understood the usage of distributed lock here. so lets say client1 writes value 10 to cache and grabs a distributed lock for that entry by talking to the locking service then when client 2 reads it from DB it knows it first needs to grab the lock so it goes the locking service, locking service notifies client1 , client1 updates the cache and release the lock and then client2 call is completed.Is my understanding right? If it is that means both client1 and client2 knows in advance they need to grab the lock before writing/reading values?
Yep that's correct
I noticed that in the video, you mentioned phrases like 'the cache asks the database for the value' or 'the cache updates the database.' My understanding, though, is that there isn't a direct connection between the cache and the database. Instead, it’s the application that detects a cache miss, fetches the value from the database, and then updates the cache. Could you clarify this part? Thanks!
Pretty sure you just described the difference of read through vs. cache aside caching
Hey just asking but do you think you'll get into ml systems design? If not can you sort of describe your process for learning what you present on the channel, i.e. starting with DDIA, then looking at the documentation for databases, etc so I can try to do the same if I ever go down that route. Also I believe you mentioned you switched from tech to finance, do you have to set up ml systems there?
Very little ML in my role in particular, and to be honest my company just isn't that into it it's not super practical in HFT but companies are starting to try to apply it more. I think you basically just named my learning process haha.
I was looking into vector databases the other day to see if they're worth talking about, and as of now the answer is maybe ;). It's a lot of math
@@jordanhasnolife5163 Ah cool! Thanks for the answer and I also appreciate the vids!
man told me to crack open a red bull for a 12 minute video
Ok I guess you can pop a Viagra next time
hey Jordan great video (when did you not have one), so for the write-around we are delegating the cache update to the read request? So on the cache miss during the read, we want to update the cache with the data from DB? Or am I missing something?
That pretty much sounds right to me!
Yes, that's the whole point. When you are there to read the data and the cache miss occurs, what choice do you have? You can only get data from the database. Then you return that data over to the user and save this data in the cache for the next requests.
FWIW you can trigger a hit to populate the cache after invalidating it, so that users don't face delays, can do this using a cron job
Your videos are 10 / 10
Hello Jordan, Regarding the distributed lock, Does the cache grabs the lock till the data is eventually written into DB? And will this be transaction specific lock or can be shared when multiple client updates the data in cache?
1) Yes
2) It would be a row level lock (or if touching multiple grab them all)
I am wondering if the read / write cache are usually the same one cache in system? And if read cache has pattern like read-through, read-around, and read-back as well?
Unless you're doing single leader replication with your caches, you'd be able to write to any.
As for your second question, these are not policies I've heard of
There are some like cache-aside, read through cache etc. but they more or less talk about the concepts in this video only.