Estimations

[00:00:00]
>> Jem Young: I do want to touch on one more topic that was brought up yesterday that I kind of hand-waved, but it's still important. Not as much talking about data, somewhat related but on estimations. Yesterday, one of the things I said very hand-waving was that, you know, this is where we left our logging service. And I said this is good for, you know, we, what we're scaling up to 100,000 users, this is perfectly fine.

[00:00:31]
We don't need multiple databases. We may not even need multiple web servers. How do I know that? How did I know that? Was I just making that up? Yes, I was making that up. But I can back that up with my assumptions, which is how it all works. So to make gustimates, as I like to call them, you know, we do estimations on our data, just to get some sort of sanity check that we're in the right ballpark.

[00:01:02]
So when you're given functional requirements or nonfunctional requirements, you want to do some sort of estimation generally. I'm going to say, I'm going to go away from the grain on all the common system interview wisdom which will go deep in estimations, and just say you just need to have a vague idea about the traffic patterns, the users, the RPS, whatever it is you're trying to measure. You don't have to be super precise.

[00:01:29]
This will go if you Google estimation system design, you're going to get very, very long. Every developer should know this, how long it takes a cache lookup versus the LRU or L1 cache versus L2 cache versus in memory versus database, you should know this back of your head. I'm going to say no, you don't need to know that. Know that in memory is faster than disk, cache is faster than the database, that's all you need to know.

[00:01:54]
But generally you want to say, do I need multiple gigabytes of storage or can I do it all in a couple of megabytes? What scale are we working at and estimations help you do that. And they really help you understand what is the thing we need to estimate, what is the most important thing we're talking about. We did that previously when it came to entity modeling, we say what's the entities here? Estimations also help with that too.

[00:02:21]
What is the most important thing? When I was with the URL shortener, the most important thing was the links and the redirects. How many redirects are happening per second. That's the thing that matters. So that's the thing we want to estimate. For our to-do app, how many tasks are we writing is probably the thing we want to estimate, how big is that size? But also estimations are a chance to show your interviewer your thought process.

[00:02:46]
I'll say real-time math I'm bad at. Math is just not a thing I keep in my head super well. So I'm not as good as estimations, but it's good to slow down and just be like, let me think logically about this problem. So the first one, and you're going to do it in like three or four minutes. You're not going to spend a lot of time on estimations, it's just give me a ballpark. What are you estimating? Number of users, RPS request per second, storage you need.

[00:03:14]
Ask or make reasonable assumptions. There's some level of, I'm going to assume this. Google used to do this for interviews. They don't do it anymore, but they do some sort of, you know, some of these like not arbitrary, kind of random interview questions like how many ping pong balls could fit on a school bus. They used to do that. I don't think they do it as much anymore. But it's designed to assess your critical thinking, not about accuracy.

[00:03:42]
No one knows how many ping pong balls fit on the school bus. But how do you get there? What's the logic you're following? And that's what you're doing with estimations is showing, what is my logic? Hey, I think a ping pong ball is two inches across. I have no idea if it's accurate. Seems about right. A school bus is, I don't know, 30 cubic feet. I have no idea. If I was better at math I'd be able to do the equation there, I'm not.

[00:04:11]
But, you know, same thing. What's another one I've heard? Oh, how many dentists are there in America? Who knows, but let me make some reasonable estimations. There's 300 million people. People go to the dentist every six months, so we say every six months, 150 billion people are going to the dentist. How many dentists do we need? Can they serve per day? I don't know, 10. And you know, you do the math from there.

[00:04:36]
Was it accurate? I don't know. Does it matter? No, it's a ballpark, and that's what estimations are all about. Don't get hung up on the details. Just talk out loud. Talk out loud, write them down. And they'll tell you like you're off by order of magnitude. Cool, thank you. Or like, yeah, that seems right, it doesn't really matter. It's close enough. Estimation is just about direction and not precision.

[00:05:08]
So then you do the math, you sanity check your results. So let's do, let's go back to our to-do app. How do I know that I can support 100, what do we say here? 1,000. We'll say 100,000 users, get up there. How do I know that the service will support 100,000 users? I could feel good about it and be like, yeah, this looks right, or we can just do some basic math to sort of validate the assumption. So how much storage space do I need?

[00:05:37]
That's going to be the main blocker here. Not request per second because we're not doing that many requests. 100,000 users just isn't that many RPS. So the big thing here, the blocker is going to be our storage. So let's make some assumptions. We already know that there's 100,000 users and we're going to say a task is 500 bytes, so 500 bytes is about 50 words. That seems like a long task, it's probably smaller than that, but again, it's just an assumption, totally fine.

[00:06:06]
I'm going to assume that people, all these users are writing three tasks a day. Just an assumption. It doesn't matter if it's right or wrong. I'm going to say there's 30 days in a month. You could say 31 days, you can say 29 days, probably less likely. It doesn't really matter. These are just my baseline assumptions, and they're going to be approximately correct. So then we just do the math. So we're doing three tasks a day, and there's 30 days in a month, and there's, what do I say?

[00:06:40]
Why'd I say 1,000 here? I see my math's already wrong. I'll fix it later. But if we're doing 100,000 users, we can say that's 90,000 tasks, the order's wrong, so it's about nine million or something like that. But we'll say 1,000 because my, just to keep the math here, I'll fix it later. So we said there's 90,000 tasks, there's 500 bytes, that's 45 million bytes, convert megabytes to bytes, 45 megabytes per month.

[00:07:11]
That's not a lot. That's pretty small. If we scale up to 100,000, you know, we're at maybe four gigs a month, pretty small. So again, directionally correct, that way, that's how I know even at 100,000 users, our database can still support that many without us having to scale up. Makes sense? Yeah. The uncomfortable thing here is like making assumptions and that feels weird as a software engineer. It's like you never make assumptions.

[00:07:40]
Things should be binary. It's right or wrong, not here. As long as you get the general idea about what is the thing you need to multiply by, what is the thing you're trying to calculate, what's the main bottleneck going to be in my system, and that's what the assumptions are all about or estimations. Also called back of the envelope calculations. I have a question. Yeah, so what is the maximum of like a typical database?

[00:08:16]
Like if, because you said this is like five gigs is like enough for this. What is like a reasonable size? Like a reasonable maximum size for one database? Anything under, we'll say 500 gigabytes. You're, you have a lot of margin there. You get to a terabyte, then you might start thinking like, oh, I should maybe shard my database at that point, maybe. Yeah, I think in gigabytes though, about anything a couple hundred gigabytes, you're safe.

[00:08:49]
Don't have to worry about it. Any database can handle that. It's, again, it doesn't have to be precise though. Hey, what, how much data can Elasticsearch hold before I ask to shard? I have no idea. No idea. But it's more, and we're talking the scale of terabytes a day, or terabytes a month or something like that, then I know I'm automatically going to need many databases at that scale. If it's gigabytes a month, I probably can, I'm safe with one.

[00:09:17]
Again, it's the direction, not precision. Yeah, I mean, generally with a lot of like when you scale up and down, I guess. You'd be a lot of those decisions I'm assuming would be made based on the monitoring you're doing from your metrics and all that in terms of performance. If you see databases really kind of chugging up like struggling, then maybe you'd want to shard or. I'm sure there's other than like storage is just going to be full, right, that'd be a pretty obvious sign to scale, but I guess what I'm asking is like, there's no like exact answer, it's kind of like a, you determine it as you go sort of situation, yeah.

[00:10:01]
You have a lot of margin on databases, as long as you get your assumptions right. So if you're like, hey, I'm only going to be doing gigabytes a month, and it actually turns out you're doing terabytes a day. Yeah, you have a problem right there. That's why you want to have some sort of baseline assumption. But if you're in the right ballpark, you'll know that, hey, my database is filling up quickly.

[00:10:28]
I have some margin to think of a strategy on how to fix that. So sharding, partitioning, things like that. But yeah, as long as you're not this way off the ballpark, you're probably safe. OK, I had an exercise to practice this, but I could tell the look on people's faces. Just know, this is one of these that is, it's easy to read about, but you get down, get there in the interview and you actually do it, it's actually pretty tricky.

[00:10:57]
This seems super easy, but trying to estimate what is the thing I need to calculate is going to be the hardest part. So something to think about. Maybe we'll, I won't make us do this, but I think, hey, what was our URL shortener? How would I estimate the redirects per second there? You know, I'm not, you don't have to answer, but how would you do that? In the banking app, what's the most important thing I need to estimate there?

[00:00:00]
Is it transactions per section? Is it reads? What is the thing that's going to bottleneck my system and how would I make that estimation based on what they told me?