In the context of large-scale data caching, when we refer to "caching," we are usually talking about using RAM to store frequently accessed data, rather than the small, high-speed CPU caches (L1, L2, L3). 75 GB of cache per machine is too much. Cache is usually is MB. So this was actually RAM we were using for caching. Systems use a portion of the machine's RAM to store cached data. This type of caching is often managed by software (e.g., Redis, Memcached). We don't need a separate "cache node" or additional hardware specifically for caching. The RAM in our existing machines is used to store cached data. When we calculated RAM requirement of 750 GB for caching. This only accounts for cache and not memory required for processing requests, running applications, and handling other system operations. So actual RAM requirement should be more than 750 GB.
I have one doubt in RAM estimation, there are 20% DAO and you consider this only, why not consider for long term(maybe different users will be active next day).
18k is average request per seconds. Request won't be evenly distributed every second.Total number of server should be for peak request per second.Suppose peak in a day is 30k per request per second so 300 server.For storage estimation average request will work.
Hi Utkarsh, you are right that 18k per sec is average computed from Daily active Users. But when the peak can happen? Based on Concurrent Users, lets say Concurrent Users is 10% of DAU (or even take 20%) and now if you will calculate the traffic, it will be very less compared to 18k per second. So i think we are good with this number and server during peek too.
Hey Shreyansh, your videos are awesome, just wanted to ask one out of the way thing, in this "remote" environment of interview how we can present our the system design in a better way? Is there any website like whimsical or any other way you would like to suggest to make it easy to deliver our thoughts with the interviewer?
Thanks for your amazing content Shrayansh. If possible, could you please make the videos in chronological order for the system design playlists. Also, if possible, maybe make a playlist for concepts of system design alongside these case study lectures. Thank you again for your awesome content
Thank you and i am making Videos in order only. If you are learning HLD or LLD, start from bottom and then move Upward. I have mentioned in the Playlist description. Hope this helps
How did you come up with the latency statistics, I am also ignoring other latency factor like network, load balancer and all, just keeping simple like server and cache but not able to relate with the stats like 95% of DAU request served in 5ms per request.
Around 05:27, it says that the estimation would not impact your design and is only intended to show the interviewer that you know these things. However, I find this to be slightly incorrect. They actually can impact your design during the interview. Think of an example where you do storage estimation. If your estimated storage values come out to be really low + based on other factors like the traffic, you might decide to shard / not shard a database or use one database over the other or even say that since the storage is low, it can even be put all in memory for faster access ( + persistence for durability). This is only one example of how things pan out, and there would be different tradeoffs or optimizations that can be introduced/rejected based on these estimations. Only for a superficial system design interview, it would not matter much.
Hi Pranjal, as per my experience with the interviews mostly interview say that they need scalable system, millions of traffic+ geographically distributed. So for my case, estimation can never be small. So we have to design for huge distributed system. But if lucky and Interviewer says we are are not expecting much traffic, then lot of things already get easy but that's my experience with Interviews, so that's why made that statement. 👍
@@ConceptandCoding Certainly.. Scalability is only one aspect of any system, however. And a "scalable" system could both be "scalable" in terms of traffic or the volume of data. There could certainly be scenarios where the traffic is huge but inherently there isn't much data to store (leaving aside entirely stateless systems altogether), for e.g. : a hit counter microservice (only keeps track of an incremented counter but servers millions of rps) or a video-on-demand streaming service (where there would only be a limited set of videos). Additionally, data can essentially be divided across systems. An example of this could be a bunch of metadata in one database while bunch of other core service data in another (depending on the characteristics of the data). The estimations for these would again lead to different optimizations and tradeoffs for the types of data itself. It could even be the other way around, less traffic but huge data (probably due to a huge catalogue + strict redundancy requirements + reverse indexing + other optimizations). Although I get your point, I think there are two things here which cannot be generalized with one statement.
@@pranjalranjansrivastava thanks Pranjal for the detailed explanation. The examples which you have taken, that totally make sense. Thanks for explaining and your feedback. Really appreciate it.
How can I avail myself of the membership on this channel. I didn't find any join button. Would anyone be able to help me? I am from Bangladesh. Thank you.
Hi Shrayansh, how the last bit of latency is calculated? I mean if 2 requests can be served in 1 second and if we have 50 threads in a server...how can we say that we can server 100 requests per second? What is the relation between threads and seconds?
Here each thread is working independently and capable of serving 2 requests per second. Since he assumed one server has 50 threads that means the server is capable of serving 50*2 = 100 requests per second.
@@vivekkumar9149 So that means the system has 50 cores? Wouldn't your assumption only be valid if the machine has 50 cores? Threads aren't the same as CPU cores
In the context of large-scale data caching, when we refer to "caching," we are usually talking about using RAM to store frequently accessed data, rather than the small, high-speed CPU caches (L1, L2, L3).
75 GB of cache per machine is too much. Cache is usually is MB. So this was actually RAM we were using for caching.
Systems use a portion of the machine's RAM to store cached data. This type of caching is often managed by software (e.g., Redis, Memcached).
We don't need a separate "cache node" or additional hardware specifically for caching. The RAM in our existing machines is used to store cached data.
When we calculated RAM requirement of 750 GB for caching. This only accounts for cache and not memory required for processing requests, running applications, and handling other system operations. So actual RAM requirement should be more than 750 GB.
perfect calculation, being mathematics student loving system design now
:) glad to know that
nice video, to the point..no bakwas or promotion. thank you
thank you
Thanks a lot, for accepting my suggestion on the last video, It's very helpful!
All doubt cleared!, love your content!
welcome Rupesh
Shrayansh, thanks for making videos in hindi, its so smooth to understand
thanks
Very valuable content! Please keep guiding and helping us like this. Thanks
Thanks, will do!
Your channel is a GEM 💎
Thank you
great video, this stuff is new to me and I had no clue what BOE was before, now I understand. thank you!
happy learning:)
Amazing sir, no one taught this :)
This video helped me to make estimation on ram and db size
Thanks
The cheat sheet is so much valuable
Sir GFaad Video, very helpful
Thanks for the knoweledge u r sharing.
Awesome, Bhai - This is really helpful.
thanks
I have one doubt in RAM estimation, there are 20% DAO and you consider this only, why not consider for long term(maybe different users will be active next day).
Brilliant explanation! Thanks a lot.
Thanks
18k is average request per seconds. Request won't be evenly distributed every second.Total number of server should be for peak request per second.Suppose peak in a day is 30k per request per second so 300 server.For storage estimation average request will work.
Hi Utkarsh,
you are right that 18k per sec is average computed from Daily active Users.
But when the peak can happen? Based on Concurrent Users, lets say Concurrent Users is 10% of DAU (or even take 20%) and now if you will calculate the traffic, it will be very less compared to 18k per second.
So i think we are good with this number and server during peek too.
Simple and nice explanation which will be highly helpful
thanks
Hey Shreyansh, your videos are awesome, just wanted to ask one out of the way thing, in this "remote" environment of interview how we can present our the system design in a better way? Is there any website like whimsical or any other way you would like to suggest to make it easy to deliver our thoughts with the interviewer?
For system design round, company so give white board online, where you can either draw or drag drop boxes.
Thank you for this cheat sheet. This is very helpful.
Thanks for this great content
Thank you
Ram is also needed for processing requests. Here you only considered memory needed for cache? Any estimations for that?
Very good content👌❤. Thank you.
Glad you liked it!
this was great
Thanks for your amazing content Shrayansh. If possible, could you please make the videos in chronological order for the system design playlists. Also, if possible, maybe make a playlist for concepts of system design alongside these case study lectures. Thank you again for your awesome content
Thank you and i am making Videos in order only. If you are learning HLD or LLD, start from bottom and then move Upward. I have mentioned in the Playlist description.
Hope this helps
@@ConceptandCoding yeah you should reverse the playlist I guess cause autoplay works forwards.😂
@@teetanrobotics5363 true, my intention is to keep latest video on top
@@ConceptandCoding but a new user is confused with this order. I took 2 days to figure out the whole thing was in reverse order
@@teetanrobotics5363 is it. Does Playlist description is not shows by RUclips, let me check and correct
How did you come up with the latency statistics, I am also ignoring other latency factor like network, load balancer and all, just keeping simple like server and cache but not able to relate with the stats like 95% of DAU request served in 5ms per request.
Is this topic important for freshers who are looking for sde-1 job?
Nice explanation
Thank you
Around 05:27, it says that the estimation would not impact your design and is only intended to show the interviewer that you know these things. However, I find this to be slightly incorrect. They actually can impact your design during the interview. Think of an example where you do storage estimation. If your estimated storage values come out to be really low + based on other factors like the traffic, you might decide to shard / not shard a database or use one database over the other or even say that since the storage is low, it can even be put all in memory for faster access ( + persistence for durability). This is only one example of how things pan out, and there would be different tradeoffs or optimizations that can be introduced/rejected based on these estimations. Only for a superficial system design interview, it would not matter much.
Hi Pranjal, as per my experience with the interviews mostly interview say that they need scalable system, millions of traffic+ geographically distributed.
So for my case, estimation can never be small. So we have to design for huge distributed system.
But if lucky and Interviewer says we are are not expecting much traffic, then lot of things already get easy but that's my experience with Interviews, so that's why made that statement. 👍
@@ConceptandCoding Certainly.. Scalability is only one aspect of any system, however. And a "scalable" system could both be "scalable" in terms of traffic or the volume of data. There could certainly be scenarios where the traffic is huge but inherently there isn't much data to store (leaving aside entirely stateless systems altogether), for e.g. : a hit counter microservice (only keeps track of an incremented counter but servers millions of rps) or a video-on-demand streaming service (where there would only be a limited set of videos). Additionally, data can essentially be divided across systems. An example of this could be a bunch of metadata in one database while bunch of other core service data in another (depending on the characteristics of the data). The estimations for these would again lead to different optimizations and tradeoffs for the types of data itself. It could even be the other way around, less traffic but huge data (probably due to a huge catalogue + strict redundancy requirements + reverse indexing + other optimizations). Although I get your point, I think there are two things here which cannot be generalized with one statement.
@@pranjalranjansrivastava thanks Pranjal for the detailed explanation.
The examples which you have taken, that totally make sense. Thanks for explaining and your feedback. Really appreciate it.
Great Video !!!
thank you
Awesome man!!
thank you
Awesome sir 🙏🙏❤️😃
Thanks a ton
@Sheryansh What is the estimation for DB server?
maja aa gya yarr padh ke
Latency part is not clear
How can I avail myself of the membership on this channel. I didn't find any join button. Would anyone be able to help me? I am from Bangladesh. Thank you.
generally at channel home page you will find join button. If not, then you can opt for Udemy
Which app and which tool are you using ? Onenote and wacom?
Yes Aritra
Btw great tutorials!! Please keep helping. 😊
How to get the no. Of load balancer?
Hi Shrayansh,
how the last bit of latency is calculated? I mean if 2 requests can be served in 1 second and if we have 50 threads in a server...how can we say that we can server 100 requests per second? What is the relation between threads and seconds?
Here each thread is working independently and capable of serving 2 requests per second. Since he assumed one server has 50 threads that means the server is capable of serving 50*2 = 100 requests per second.
@@vivekkumar9149 So that means the system has 50 cores? Wouldn't your assumption only be valid if the machine has 50 cores? Threads aren't the same as CPU cores
how did u come with latency no. is it random or from above calculation ?
I need to check the video, will update you, as far as I can recall, it's estimate or approx numbers
Thank you
👍
Hi shrayash, Can you please provide notes of all these videos that you have recorded
I will try to add buddy
@@ConceptandCoding Thanks that great 👍
Too much ads Shreyansh..😢
👍👍
wow
superb explanation. 150524
Bhai notes toh dediya kro😢
Please don't make it private
I prefer Hindi not English ( English is just a instruction language to me and most of the indians)
:) but as an SDE apko English bahot help karegi team se Collab karne mein and aage badne mein buddy
I came here from US. English would reach a broader audience.
superb explanation @150524
luchkudari luchkudari amazon sde2.... i wish he b layoff/......