hey guys it's Johan and welcome back to system Design Concepts for beginners in this video I want to talk about how to do capacity estimations in a system design interview most system design interviews especially with big companies will have a section of the interview that is dedicated to capacity estimations usually right after you're done asking some clarifying questions about the requirements of the system you'll be expected to estimate some numbers that in theory should guide your design I say in theory because normally in this type of interview those numbers wouldn't really affect your design I mean you'll be designing a large-scale system large and larger look pretty similar in terms of architecture a lot of the times we'll be doing these estimations and move on with the interview without ever using them for anything so you might be asking yourself why am I even doing this well the annoying answer is they simply expected of you over time big tech companies kind of adopted the structure for system design interviews and capacity estimations is just a part of this structure in real life though those estimations are actually very important the meant to help you determine the amount of resources you'll need for the system to function at a high level things like number of servers number of data partitions amount of memory for cash and so on some interviewers might ask you about those resources and others will not in a way those estimations do serve a purpose even if you don't end up using them estimating these type of figures using just a few assumptions a bit of Common Sense and an organized way of thinking shows a lot about the way you approach problems and in my opinion this is the real reason why you should do Dominion interview in this video I'm going to show you which numbers you need to estimate how to estimate them and how to do it quickly you don't want to spend more than five minutes on this and everything in this video is of course a suggestion there are a million different ways to go about this but I find that this one works for me I like order I like steps I like to know exactly what to do next so if you like that too let's get straight into it the estimations are important for large scale system design are traffic storage bandwidth and memory for caching in this video we're going to do all of them them but in my opinion doing traffic and storage is more than enough in an interview of course if you feel comfortable and can do all of them really quickly then go right ahead and do that but again don't spend more than five minutes on this so let's start with traffic estimation the only number that we need is an input for this is the number of users that our service is expected to support or better yet the number of daily active users this is something that we should ask the interviewer as a clarifying question at the start of the interview we should simply ask how many daily active users is a service expected to support and say that this number is 10 million first thing we have to do is convert users to requests because our resources our servers our databases they don't actually care about the concept of users right they care about the number of requests they would have to serve a single active user can generate multiple interactions with the service right it can generate multiple API calls read and write requests that our service will have to handle in reasonable time so at this point we need to consider how a typical user will use the service how many write requests would it generate per day and how many read requests for example let's say we're designing a paste bin type service where users can upload a chunk of text and get back a shareable link the shareable link can later be used to view the paste uploading paste would be a write request and viewing the paste would be a read request we have 10 million daily active users that's our starting point I can make the assumption that only 10 of those users actually upload new pace and when they do they will probably upload on average one pay start day so we have one million white requests per day next we need to determine if the service is going to be read heavy or white heavy in general most services will be read heavy as opposed to write heavy because users tend to consume data much more than produce it for example if you're using YouTube you're probably going to watch many more videos then upload new ones on the opposite side you have services that are more right heavy some examples are services that do analytics monitoring and logging in those cases you'll be writing data far more often than reading it but in our case our service is going to be read heavy because we expect users to view paste more often than upload them and once we've established that we can choose a read to write ratio that makes sense to us 10 to 1 50 to 1 100 to 1 each of these will be fine so let's say we choose 50 to 1. it means that each day we'll be dealing with 50 read requests for each one of the 1 million write requests so we'll have 50 million read requests per day next we want to get this number down from per day to per second because we rarely measure performance on bottlenecks at a scale of a day we need to get them in seconds so that's the second step in Traffic estimation to get the number of write requests per second we have to divide this number by the number of seconds there are in a day there are 60 seconds in a minute 60 minutes in an hour and 24 hours in a day 60 multiplied by 60 is 3600 and now this this is too much for me I mean I can't just do this in my head in two seconds and no one wants to see you do long multiplication or division in a system design interview so what you should do is always round your number to a convenient power of 10. don't calculate this calculate this this is way more manageable and it's easier to just see that it's adk without thinking too much and now in order to make this division easier we were wound it up again to 100K this point is key with capacity estimations I cannot stress this enough approximate aggressively it will make your life so much easier so we have approximately 100K seconds in a day which means that the average number of write requests per second is 1 million divided by 100K which is 10 and weeds are 50 times that number so that's 500 with requests per second and that is all we need for traffic let's move on to storage we need to estimate how much data we'll have to store at any given moment remember we don't have to be super accurate with this we only want to give a ballpark estimation so we don't need to calculate the required storage for every table we plan to keep in our database what we should do is first determine what kind of data artifacts will have to store and then focus on the one that will require the largest amount of disk space for example for our basement service we will need to store the paste that our users upload and we will also need to store the URLs that we generate and send back to the users right now we can say that the storage that we'll need for the URLs will for sure be negligible compared to what we'll need for the pace because we need one URL per paste and the size of the URL is significantly smaller than the size of the base so it would be reasonable to focus only on the storage for the pace so how much storage will we need to store our user space we can say that because users usually use pay services to share code Snippets logs and stuff like that and average pay size will not be too large it might contain around 200 lines of text we can estimate that each line contains about 10 words and each word has five letters or characters and of course each character consumes one byte of storage which means that the average pay size will be 10 000 bytes which is 10 kilobytes we have 1 million write requests per day this means we'll get 1 million multiplied by 10 kilobytes of new data per day now for me it's not obvious just by looking at this how much this is right so I want to take a small detour here and show you how I would calculate this in a system design interview one byte is the smallest unit then you have a kilobyte which is a thousand bytes the number thousand has three zeros so it's 10 to the power of three by the way in base 2 a kilobyte is actually 2 to the power of 10 which is 1024 bytes but we can stick with decimal for our purpose it's easier to calculate and it's good enough next we have a megabyte which is a million bytes that's three more zeros which is 10 to the power of six then a gigabyte which is a billion bytes 10 to the power of 9 then we have a terabyte which is a trillion bytes we add three more zeros to get 10 to the power of 12 and finally a petabyte which is quadrillion bytes and that's another three zeros so 10 to the power of 15. now if we're trying to calculate 1 million requests multiplied by 10 kilobytes then we just replace these letters with powers of 10. a million is 10 to the power of 6 and a kilo is 10 to the power of 3. for multiplication we just add those Powers so we get 10 multiplied by 10 to the power of 9 which is 10 gigabytes so I recommend you just remember those conversions and then it's easy to just add the number of zeros for multiplication or subtract them for division okay let's get back to our problem we now know that we have to store 10 gigabytes of new data per day but what about the new data from yesterday and the day before and the day before that we don't start fresh every morning right so we have to consider the retention period of our data we can ask the interviewer if our paste come with an expiration date if faces expire after five years then at any given moment we will have to store all the paste generated in the five years prior to that moment in the case where there is no expiration date like Facebook posts for example you know when you upload a post to Facebook you expect this post will exist forever right so in this case it will probably be an enough to calculate the storage for a period of 10 years but let's say our Pace do have an expiration time of five years there are 365 days in a year let's round it up to 400. and each day we add 10 gigabytes of new data 5 multiplied by 400 is 2K this is 20. K has three zeros Giga has nine so we have 12 zeros and that is 20 terabytes which means that in order to store five years of new Pace we will need 20 terabytes now we're probably going to want to replicate our data for backup and to improve availability and performance it's common to replicate the data three to five times let's say we do three so in total we're going to need 60 terabytes and that's all we need for storage estimation if you decide to also do bandwidth this is how it will go bandwidth is the amount of data transferred per second we need to compute the amount of incoming data per second that's the data coming in from write requests and the amount of outgoing data per second which is the data that our service returns as a reply to read requests we have 10 write requests per second the size of each write request is equal to the size of the paste that is being uploaded which we estimated at 10 kilobytes so we will need to support 100 kilobytes of incoming data per second similarly we have 500 bid requests per second each read request which is a request to view a paste will be served with 10 kilobytes the average size of the paste so we will need to support five megabytes of outgoing data per second lastly let's do memory for cache caching is a way to serve read requests Faster by keeping common responses closer for fast retrieval it's common to use the 80 20 rule for caching it means that we assume that 20 of the pace will be so popular that they will generate 80 of the traffic so we would like to Cache those popular twenty percent we have 50 million daily read requests each served with a 10 kilobyte paste we'd like to Cache 20 of these twenty percent of 10 kilobyte is 2 kilobyte so we have 50 million multiplied by two kilobytes 50 multiplied by two is one hundred a million has six zeros kilo has three so nine zeros which is a gigabyte so you will need 100 gigabyte for caching and actually we will need less than that because we probably counted duplicate requests here some of these will be requesting to view the same paste and in practice we will only store it once so actual memo usage will be less than 100 gigabytes now I want to do an example of how you would use these numbers for resource decisions for example you might be asked how many application servers are required to handle this load the formula for this is the number of requests per second that we need to support we just estimated that this number is around 500 divided by the number of requests per second that the single server can handle this number will obviously vary drastically depending on the server's hardware and the time it takes to process a single request it's also important to determine whether the request is CPU bound memory bound or IO Bound by the very very high level if the request is CPU bound then the formula for this number will be the number of physical cores our servers have divided by the number of time it takes to process a single request so if we use servers with eight cores and the time it takes to process one request is half a second then a single server will be able to handle 16 requests per second the logic behind this is that on a single physical core where there is no parallel work we'll be able to process two requests per second right because one request takes half a second we'll be able to fit two of them in one second so a single core can take two requests per second and we have eight of these doing that in parallel so we'll be able to take a times this number that is why we get 16. so this number is 16 then the number of servers we'll need will be 500 divided by 16. so we can say that we'll need 30 to 50 servers to handle this load the last thing I want to cover in this video is some common sizes and estimations that might be relevant for other examples we'll do language and media estimations that have to do with language are useful for estimating text and document sizes and also index sizes for search it will be helpful to remember these approximations there are 500k words in the English language a line of text contains 10 words an English word contains five characters which is five bytes media related numbers are for images and videos an HD image that might be used in an Instagram or Facebook post will be around three megabytes the size of an image is determined by the number of pixels it has multiplied by the size of each pixel the size of the pixel is also called the bit depth of the image an HD image has 1280 over 720 pixels and a common bit depth is 24 bits which is 3 bytes if we do a bit of rounding we'll get 1K multiplied by 1K multiplied by 3 bytes which is three megabytes profile images will be smaller around 300 over 300 pixels so the size will be 300 kilobytes videos are a bit more complicated because the size depends on frame size frame rate compression ratio and of course duration but as a rough estimate we can say that one minute of HD video is around 50 megabytes the frame size of an HD video is the same as an HD image so three megabytes assuming our video is a frame rate of 30 frames per second we'll get 90 megabytes per second we can use velocity compression with a compression ratio of 100 to 1 and to get the number per minute we'll multiply it by 60. so we get this formula and if we simplify this a bit we will get 54 megabytes so we can say it's 50 megabytes now usually we would like to store the same video with lower resolutions as well if you're designing YouTube for example you'll also need 480p 360p 240p and 144p we can estimate that the sum of these sizes for these lower resolutions is actually equal to the size of the original HD video because if the size of 720p is X the size of this one would be x divided by 2 and for this one x divided by 4 and so on the sum of this series is X so in total we will need 2x megabytes which is 2 multiplied by 50 megabytes that's 100 megabyte to store all these different formats so that is it for this one I hope you enjoyed this video as always thank you for watching and I will see you next time foreign