WEBVTT 1 00:00:01.450 --> 00:00:04.240 So let's begin specifically talking about scalability. 2 00:00:04.240 --> 00:00:05.510 How do you design systems 3 00:00:05.510 --> 00:00:08.670 that can handle millions of people hitting it all at once? 4 00:00:08.670 --> 00:00:10.180 At Amazon, when I was there, 5 00:00:10.180 --> 00:00:12.240 it was routine for our servers to have to handle 6 00:00:12.240 --> 00:00:15.130 tens of thousands of transactions per second. 7 00:00:15.130 --> 00:00:16.860 I'm sure it's gotten even worse since I've left, 8 00:00:16.860 --> 00:00:18.640 but modern techniques allow you 9 00:00:18.640 --> 00:00:20.440 to horizontally scale these systems 10 00:00:20.440 --> 00:00:22.670 such that they can actually handle that traffic. 11 00:00:22.670 --> 00:00:23.790 And if you get more traffic, 12 00:00:23.790 --> 00:00:25.140 you just throw more servers at it. 13 00:00:25.140 --> 00:00:27.603 So let's see how that works exactly. 14 00:00:29.370 --> 00:00:31.970 Let's start by talking about a single-server design. 15 00:00:31.970 --> 00:00:34.700 So we're gonna start with a design that does not scale, 16 00:00:34.700 --> 00:00:36.810 and we're gonna work our way up to one that does. 17 00:00:36.810 --> 00:00:39.730 So in a sort of legacy single-server design, 18 00:00:39.730 --> 00:00:40.780 you have a bunch of clients 19 00:00:40.780 --> 00:00:41.960 out there in the internet, right? 20 00:00:41.960 --> 00:00:45.250 People running their phones or laptops or PCs, 21 00:00:45.250 --> 00:00:46.400 whatever they might be. 22 00:00:46.400 --> 00:00:48.120 And they are coming through the internet, 23 00:00:48.120 --> 00:00:50.170 which is what this cloud represents. 24 00:00:50.170 --> 00:00:52.570 And they talk to one box on the other side. 25 00:00:52.570 --> 00:00:55.830 So my personal website, for example, is set up this way. 26 00:00:55.830 --> 00:00:57.160 It doesn't get a whole lot of traffic 27 00:00:57.160 --> 00:00:58.600 and I don't really care too much 28 00:00:58.600 --> 00:00:59.650 if it goes down for a while. 29 00:00:59.650 --> 00:01:02.210 So, hey, one server's enough for that, 30 00:01:02.210 --> 00:01:04.360 for my personal thing where I keep my hobbies. 31 00:01:04.360 --> 00:01:05.210 No big deal. 32 00:01:05.210 --> 00:01:07.590 I make sure the data's backed up somewhere 33 00:01:07.590 --> 00:01:08.900 so I can restore it if I need to, 34 00:01:08.900 --> 00:01:11.958 but it just doesn't get enough traffic 35 00:01:11.958 --> 00:01:13.460 for me to care about it that much. 36 00:01:13.460 --> 00:01:14.730 And I don't really care if it goes down 37 00:01:14.730 --> 00:01:16.300 for a length of time either. 38 00:01:16.300 --> 00:01:17.650 That's really the only situation 39 00:01:17.650 --> 00:01:19.680 where you'd want to deal with a single-server design. 40 00:01:19.680 --> 00:01:21.980 But sometimes that is the right solution. 41 00:01:21.980 --> 00:01:23.500 Maybe there's some little internet tool 42 00:01:23.500 --> 00:01:25.080 that just isn't that important 43 00:01:25.080 --> 00:01:26.340 and you don't have a lot of budget for, 44 00:01:26.340 --> 00:01:28.860 and you don't want to spend a lot of time maintaining it. 45 00:01:28.860 --> 00:01:30.883 So it still has its place. 46 00:01:32.210 --> 00:01:34.070 That's just running HTTP of some sort 47 00:01:34.070 --> 00:01:36.300 and maybe there's WordPress or something on top of that. 48 00:01:36.300 --> 00:01:37.133 I don't know. 49 00:01:37.133 --> 00:01:39.110 But the protocol is HTTP, generally speaking, 50 00:01:39.110 --> 00:01:40.270 talking to the web. 51 00:01:40.270 --> 00:01:42.390 And there's probably some database as well. 52 00:01:42.390 --> 00:01:44.410 Again, for a really small website, 53 00:01:44.410 --> 00:01:47.010 maybe that database resides on that server itself. 54 00:01:47.010 --> 00:01:49.810 Again, that's how my personal web server runs. 55 00:01:49.810 --> 00:01:53.200 That's just serving stuff about my hobbies. 56 00:01:53.200 --> 00:01:54.680 Why spend more money on it than that? 57 00:01:54.680 --> 00:01:56.720 It just has a little MySQL instance running on there 58 00:01:56.720 --> 00:01:59.210 in the same server as my Apache instance. 59 00:01:59.210 --> 00:02:01.040 And it's all on WordPress or whatever. 60 00:02:01.040 --> 00:02:02.560 Doesn't matter. 61 00:02:02.560 --> 00:02:04.810 But of course, if you're gonna be doing this 62 00:02:04.810 --> 00:02:05.910 for a real commercial system, 63 00:02:05.910 --> 00:02:07.510 this is a terrible idea, right? 64 00:02:07.510 --> 00:02:09.680 I mean, that host is a single point of failure. 65 00:02:09.680 --> 00:02:13.090 So if that box goes down, I'm gonna have a really bad day 66 00:02:13.090 --> 00:02:15.330 if I care about what that box was doing, right? 67 00:02:15.330 --> 00:02:17.440 I'm gonna have to go and provision a new server. 68 00:02:17.440 --> 00:02:19.840 I'm gonna have to restore everything on it from a backup, 69 00:02:19.840 --> 00:02:22.480 and I'll probably have to go switch the DNS entry somewhere 70 00:02:22.480 --> 00:02:23.660 to point to that new server 71 00:02:23.660 --> 00:02:25.410 so that people can actually hit it. 72 00:02:25.410 --> 00:02:28.090 And this does happen to me pretty often 73 00:02:28.090 --> 00:02:29.100 with my personal site. 74 00:02:29.100 --> 00:02:30.250 It's kind of a pain. 75 00:02:30.250 --> 00:02:32.480 And if this was happening on a real commercial system 76 00:02:32.480 --> 00:02:34.750 where I'm getting paged about it at two in the morning, 77 00:02:34.750 --> 00:02:36.220 I would not want to deal with that. 78 00:02:36.220 --> 00:02:38.980 So generally speaking, 79 00:02:38.980 --> 00:02:40.360 unless you're specifically being asked 80 00:02:40.360 --> 00:02:43.210 to develop something that is unimportant in small scale, 81 00:02:43.210 --> 00:02:45.470 which is pretty unlikely in a system design interview, 82 00:02:45.470 --> 00:02:47.570 this is not the approach you want to take. 83 00:02:48.940 --> 00:02:50.460 So how can we make this better? 84 00:02:50.460 --> 00:02:51.293 Well, one thing we can do 85 00:02:51.293 --> 00:02:52.900 is to separate out the database, at least. 86 00:02:52.900 --> 00:02:54.610 So again, let's start at the top here. 87 00:02:54.610 --> 00:02:56.170 We have all the clients in the world out there 88 00:02:56.170 --> 00:02:57.670 that want to hit your system, 89 00:02:57.670 --> 00:02:59.680 and they're connecting to you through the internet somehow. 90 00:02:59.680 --> 00:03:02.610 They're being routed from all over the globe to someplace. 91 00:03:02.610 --> 00:03:04.210 And again, in this case, 92 00:03:04.210 --> 00:03:06.150 we'll just have a single HTTP server, 93 00:03:06.150 --> 00:03:06.983 but we're gonna at least 94 00:03:06.983 --> 00:03:09.640 split out the database part of this, right? 95 00:03:09.640 --> 00:03:11.010 Well, that's a little bit better. 96 00:03:11.010 --> 00:03:15.420 So at least now I'm not gonna lose my web server 97 00:03:15.420 --> 00:03:17.870 and data and my pages and the database itself 98 00:03:17.870 --> 00:03:19.440 all at the same time. 99 00:03:19.440 --> 00:03:20.750 They're actually scaled independently. 100 00:03:20.750 --> 00:03:24.130 So that's a little bit better from a resiliency standpoint. 101 00:03:24.130 --> 00:03:25.950 Not much though, right? 102 00:03:25.950 --> 00:03:27.260 But the real benefit of this 103 00:03:27.260 --> 00:03:29.860 is that I can scale these two things independently. 104 00:03:29.860 --> 00:03:31.280 So let's say I have an application 105 00:03:31.280 --> 00:03:33.530 that's really hitting the database hard. 106 00:03:33.530 --> 00:03:37.560 That might be eating up a lot of CPU time on my web server, 107 00:03:37.560 --> 00:03:40.270 where I'm spending more time in my database processes 108 00:03:40.270 --> 00:03:42.210 than in my HTTP processes, right? 109 00:03:42.210 --> 00:03:45.610 Maybe MySQL is eating up all my resources 110 00:03:45.610 --> 00:03:46.910 and not leaving enough resources 111 00:03:46.910 --> 00:03:50.300 for the web to actually serve enough connections. 112 00:03:50.300 --> 00:03:51.480 So kind of the next step up 113 00:03:51.480 --> 00:03:52.850 for scaling up a system like that, 114 00:03:52.850 --> 00:03:53.700 where we have one server, 115 00:03:53.700 --> 00:03:55.380 is to at least scale out the database. 116 00:03:55.380 --> 00:03:58.630 And now I have two computers out there instead of one 117 00:03:58.630 --> 00:04:00.530 that I can spread resources around, 118 00:04:00.530 --> 00:04:03.030 and I can scale those independently, right? 119 00:04:03.030 --> 00:04:05.840 So I can choose a beefier box for the database 120 00:04:05.840 --> 00:04:07.920 if I have a really data-intensive application 121 00:04:07.920 --> 00:04:11.060 that's doing complicated joins or whatever it is, 122 00:04:11.060 --> 00:04:12.160 and maybe something less powerful 123 00:04:12.160 --> 00:04:14.170 for the front-end web server, if that's appropriate. 124 00:04:14.170 --> 00:04:15.980 So that gives me a little more control 125 00:04:15.980 --> 00:04:18.730 over how I scale these things, which is good. 126 00:04:18.730 --> 00:04:20.300 But still, these are both 127 00:04:20.300 --> 00:04:21.810 single points of failures now, right? 128 00:04:21.810 --> 00:04:24.730 So if my database goes down, my website goes down. 129 00:04:24.730 --> 00:04:27.480 If my web server goes down, my website goes down. 130 00:04:27.480 --> 00:04:30.723 So from a resiliency standpoint, not really any better. 131 00:04:31.900 --> 00:04:33.970 So let's talk about one way of scaling up further. 132 00:04:33.970 --> 00:04:36.290 Let's say that I do want to take more traffic 133 00:04:36.290 --> 00:04:38.900 than I could have handled on that one server originally. 134 00:04:38.900 --> 00:04:40.370 Again, we start with our clients 135 00:04:40.370 --> 00:04:42.030 connecting through the internet, 136 00:04:42.030 --> 00:04:44.350 and maybe I just throw a bigger server at it. 137 00:04:44.350 --> 00:04:46.960 This is what we call vertical scaling. 138 00:04:46.960 --> 00:04:48.180 So vertical scaling 139 00:04:48.180 --> 00:04:49.810 means that instead of adding more servers, 140 00:04:49.810 --> 00:04:51.480 I just add a bigger server, 141 00:04:51.480 --> 00:04:54.760 and that can get you to a certain point, right? 142 00:04:54.760 --> 00:04:56.160 For a long time with databases, 143 00:04:56.160 --> 00:04:57.540 that's kind of what we did. 144 00:04:57.540 --> 00:04:59.920 You started off with an Oracle instance running somewhere, 145 00:04:59.920 --> 00:05:02.300 and as you threw more and more traffic at it 146 00:05:02.300 --> 00:05:03.510 and more and more data at it, 147 00:05:03.510 --> 00:05:05.500 the way to make it scale was to just get a bigger 148 00:05:05.500 --> 00:05:07.070 and more expensive database host. 149 00:05:07.070 --> 00:05:09.380 And these things got really, really expensive, 150 00:05:09.380 --> 00:05:10.950 really, really quickly. 151 00:05:10.950 --> 00:05:12.770 Same thing applies to your web server here. 152 00:05:12.770 --> 00:05:17.770 So I have a big, fat host here running HTTPD presumably, 153 00:05:18.430 --> 00:05:20.470 and maybe instead of a little virtual machine 154 00:05:20.470 --> 00:05:21.640 running on one CPU, 155 00:05:21.640 --> 00:05:24.040 I'm running a whole machine here now or something, 156 00:05:24.040 --> 00:05:26.350 or at least a bigger virtual machine, right? 157 00:05:26.350 --> 00:05:28.610 So to some extent, 158 00:05:28.610 --> 00:05:31.280 you can just throw more hardware at the problem 159 00:05:31.280 --> 00:05:33.170 and get away with that for a little while. 160 00:05:33.170 --> 00:05:36.060 So if I have a little personal website that, again, 161 00:05:36.060 --> 00:05:37.530 I don't care too much about 162 00:05:37.530 --> 00:05:39.440 and it suddenly gets a surge of traffic, 163 00:05:39.440 --> 00:05:41.060 maybe I deal with that by just throwing 164 00:05:41.060 --> 00:05:43.010 a bigger virtual machine at it. 165 00:05:43.010 --> 00:05:45.240 And in fact, that's what I'm doing right now. 166 00:05:45.240 --> 00:05:46.850 I've had some websites of my own 167 00:05:46.850 --> 00:05:49.050 that kind of buckled under the pressure 168 00:05:49.050 --> 00:05:51.260 of crawlers hitting them, in particular. 169 00:05:51.260 --> 00:05:53.710 And by just throwing a bigger virtual machine at it, 170 00:05:53.710 --> 00:05:54.910 it solved that problem. 171 00:05:54.910 --> 00:05:56.500 But again, not something 172 00:05:56.500 --> 00:05:58.010 you generally want to be doing in production 173 00:05:58.010 --> 00:06:00.310 because vertical scaling has its limits. 174 00:06:00.310 --> 00:06:03.030 You can only get so big of a computer 175 00:06:03.030 --> 00:06:05.130 before you can't get anything bigger. 176 00:06:05.130 --> 00:06:07.290 There's only so many CPUs you can get in a system, 177 00:06:07.290 --> 00:06:08.730 there's only so much memory. 178 00:06:08.730 --> 00:06:10.860 At some point, you're gonna hit a wall. 179 00:06:10.860 --> 00:06:13.680 So vertical scaling only gets you so far, 180 00:06:13.680 --> 00:06:15.540 but you need to know what it is. 181 00:06:15.540 --> 00:06:17.880 Similarly, I can make the database server bigger too. 182 00:06:17.880 --> 00:06:18.930 We talked about that a little bit 183 00:06:18.930 --> 00:06:21.530 in the context of like a giant Oracle database. 184 00:06:21.530 --> 00:06:22.920 Same idea. 185 00:06:22.920 --> 00:06:24.020 Maybe I need more storage. 186 00:06:24.020 --> 00:06:28.120 Maybe I need more CPU power for processing those queries. 187 00:06:28.120 --> 00:06:30.330 To a point, I can just throw bigger and bigger 188 00:06:30.330 --> 00:06:34.230 and more powerful machines at my database server and scale, 189 00:06:34.230 --> 00:06:36.623 to an extent, just that way. 190 00:06:38.210 --> 00:06:39.950 The only good thing about this 191 00:06:39.950 --> 00:06:42.950 is that there's not a lot of things to maintain, right? 192 00:06:42.950 --> 00:06:43.783 So in this system, 193 00:06:43.783 --> 00:06:46.010 I still only have two hosts to take care of. 194 00:06:46.010 --> 00:06:48.220 So that's kind of a plus, right? 195 00:06:48.220 --> 00:06:50.360 The fewer computers that I have, 196 00:06:50.360 --> 00:06:51.900 the fewer servers that I have, 197 00:06:51.900 --> 00:06:53.890 the fewer things that are likely to break 198 00:06:53.890 --> 00:06:55.230 in any given day, okay? 199 00:06:55.230 --> 00:06:57.750 But when it does break, I'm in trouble, right? 200 00:06:57.750 --> 00:07:00.030 Either of those things goes down, my website's down 201 00:07:00.030 --> 00:07:01.220 and it's gonna stay down 202 00:07:01.220 --> 00:07:04.810 until I can replace that host with something else, right? 203 00:07:04.810 --> 00:07:07.443 Maybe that's okay, probably isn't though. 204 00:07:09.500 --> 00:07:11.160 So again, just to summarize there, 205 00:07:11.160 --> 00:07:12.950 servers only come so large. 206 00:07:12.950 --> 00:07:13.783 That is the problem. 207 00:07:13.783 --> 00:07:16.280 So you still have single points of failure here. 208 00:07:16.280 --> 00:07:17.480 The only upside of this 209 00:07:17.480 --> 00:07:19.633 is that you have fewer servers to maintain. 210 00:07:21.670 --> 00:07:23.120 Now, horizontal scaling. 211 00:07:23.120 --> 00:07:24.670 This is kind of where it's at. 212 00:07:24.670 --> 00:07:25.920 So it's a pretty safe bet 213 00:07:25.920 --> 00:07:28.120 that for most modern system design problems, 214 00:07:28.120 --> 00:07:30.450 where you're being asked to develop a system at large scale, 215 00:07:30.450 --> 00:07:34.070 they want you to take a more horizontal scaling approach. 216 00:07:34.070 --> 00:07:36.210 So again, you have your clients out there in the world 217 00:07:36.210 --> 00:07:37.560 hitting you through the internet. 218 00:07:37.560 --> 00:07:39.780 The idea here is that instead of a single server, 219 00:07:39.780 --> 00:07:41.570 you have multiple servers 220 00:07:41.570 --> 00:07:43.320 and you have some sort of a load balancer 221 00:07:43.320 --> 00:07:44.810 between the internet and those servers 222 00:07:44.810 --> 00:07:48.970 that are distributing that load in some fair, even manner. 223 00:07:48.970 --> 00:07:51.100 We could talk about load balancers strategies. 224 00:07:51.100 --> 00:07:54.010 There's round robin, there's partitioning it, 225 00:07:54.010 --> 00:07:56.350 there's load bouncers that can actually 226 00:07:56.350 --> 00:07:58.440 look at the available capacity on a server 227 00:07:58.440 --> 00:08:01.220 and try to route traffic intelligently that way. 228 00:08:01.220 --> 00:08:03.650 So that's a whole other can of worms. 229 00:08:03.650 --> 00:08:06.020 But the idea is that there is some, 230 00:08:06.020 --> 00:08:08.320 either device or software process running somewhere 231 00:08:08.320 --> 00:08:11.030 that is distributing that load coming in from the internet 232 00:08:11.030 --> 00:08:12.840 to a whole fleet of servers. 233 00:08:12.840 --> 00:08:15.620 So the beauty of that is that if one of those goes down, 234 00:08:15.620 --> 00:08:18.410 assuming I have enough excess capacity provisioned, 235 00:08:18.410 --> 00:08:19.670 the user doesn't need to know. 236 00:08:19.670 --> 00:08:22.640 The load bouncer can realize that a host is down 237 00:08:22.640 --> 00:08:24.730 and reroute the traffic around it automatically 238 00:08:24.730 --> 00:08:26.410 so that you have no downtime. 239 00:08:26.410 --> 00:08:27.730 Pretty cool, right? 240 00:08:27.730 --> 00:08:30.280 Maybe they all still point to a single database. 241 00:08:30.280 --> 00:08:32.570 We could scale that out as well, if we wanted to, 242 00:08:32.570 --> 00:08:34.020 but in this case, 243 00:08:34.020 --> 00:08:36.930 maybe our database isn't really a choke point 244 00:08:36.930 --> 00:08:38.740 and we have good redundancy on it somehow. 245 00:08:38.740 --> 00:08:40.890 We'll get more to database scaling later on, 246 00:08:40.890 --> 00:08:42.790 but at least in this architecture, 247 00:08:42.790 --> 00:08:46.860 our front-end web servers are gonna keep on serving, right? 248 00:08:46.860 --> 00:08:47.970 Maybe they have some sort of a cache 249 00:08:47.970 --> 00:08:48.803 in front of the database, 250 00:08:48.803 --> 00:08:50.700 so they can still do something meaningful 251 00:08:50.700 --> 00:08:52.170 if that database were to go down. 252 00:08:52.170 --> 00:08:54.290 But the idea of horizontal scaling 253 00:08:54.290 --> 00:08:56.150 is that as I get more and more traffic, 254 00:08:56.150 --> 00:08:58.300 I just add more and more servers to the fleet 255 00:08:58.300 --> 00:09:00.600 and the load balancer will distribute that traffic 256 00:09:00.600 --> 00:09:02.600 amongst those servers. 257 00:09:02.600 --> 00:09:04.720 So you can see, you can pretty much scale infinitely 258 00:09:04.720 --> 00:09:05.810 with this idea, right? 259 00:09:05.810 --> 00:09:09.180 If I have millions of transactions coming in, 260 00:09:09.180 --> 00:09:11.840 throw in enough servers in there and you'll be good. 261 00:09:11.840 --> 00:09:13.810 There are some finer points about, 262 00:09:13.810 --> 00:09:15.950 where these are located geographically 263 00:09:15.950 --> 00:09:17.650 and what servers, what data centers. 264 00:09:17.650 --> 00:09:18.483 We'll get into that. 265 00:09:18.483 --> 00:09:21.490 But this is the basic idea of horizontal scaling. 266 00:09:21.490 --> 00:09:22.800 It allows an infinite, 267 00:09:22.800 --> 00:09:25.770 well, practically infinite way of scaling things up, 268 00:09:25.770 --> 00:09:27.890 where the more servers you can throw in there, 269 00:09:27.890 --> 00:09:29.090 the more traffic you can handle. 270 00:09:29.090 --> 00:09:31.270 There's really no bound to it in this case. 271 00:09:31.270 --> 00:09:32.180 The downside, of course, 272 00:09:32.180 --> 00:09:34.130 is that there's more stuff to maintain. 273 00:09:35.060 --> 00:09:39.080 So let's talk about stateful and stateless stuff here. 274 00:09:39.080 --> 00:09:42.870 So the catch here is that this really only works well 275 00:09:42.870 --> 00:09:45.650 if your web servers are what we call stateless. 276 00:09:45.650 --> 00:09:48.320 What I mean by that is that subsequent requests 277 00:09:48.320 --> 00:09:51.440 should not depend on something being stored on that server 278 00:09:51.440 --> 00:09:53.670 from a previous request, okay? 279 00:09:53.670 --> 00:09:55.500 Now, you can store stuff in the database. 280 00:09:55.500 --> 00:09:56.580 That's fine. 281 00:09:56.580 --> 00:09:57.870 But the servers themselves, 282 00:09:57.870 --> 00:09:59.840 those web servers need to be stateless 283 00:09:59.840 --> 00:10:01.330 because I don't know 284 00:10:01.330 --> 00:10:03.350 where that previous request got routed to. 285 00:10:03.350 --> 00:10:05.900 So I cannot assume on any given server 286 00:10:05.900 --> 00:10:09.170 that I have any information about the previous hits 287 00:10:09.170 --> 00:10:10.610 from that given user, right? 288 00:10:10.610 --> 00:10:14.720 So a stateless web server means that any web server 289 00:10:14.720 --> 00:10:17.800 can handle any request at any time, okay? 290 00:10:17.800 --> 00:10:19.430 Again, it's okay to use the database 291 00:10:19.430 --> 00:10:21.520 to tie those together and have sort of a history, 292 00:10:21.520 --> 00:10:25.090 but any individual server cannot assume that that server 293 00:10:25.090 --> 00:10:26.830 is the one that actually served 294 00:10:26.830 --> 00:10:28.960 previous requests to a given user. 295 00:10:28.960 --> 00:10:30.370 That's what I mean by stateless. 296 00:10:30.370 --> 00:10:34.530 It just means that we're baking in the assumption 297 00:10:34.530 --> 00:10:37.090 that any request for a user could have gone to any server. 298 00:10:37.090 --> 00:10:38.930 And we cannot assume that our server 299 00:10:38.930 --> 00:10:41.715 knows anything about those previous requests directly. 300 00:10:41.715 --> 00:10:42.573 Okay? 301 00:10:45.380 --> 00:10:47.950 So how do you go about choosing one of those architectures? 302 00:10:47.950 --> 00:10:50.300 Well, in general, a theme in this course 303 00:10:50.300 --> 00:10:53.160 that I'm gonna be preaching is simplicity. 304 00:10:53.160 --> 00:10:55.340 You should always choose the simplest architecture 305 00:10:55.340 --> 00:10:57.550 that meets your projected requirements, 306 00:10:57.550 --> 00:10:59.750 but no simpler than that. 307 00:10:59.750 --> 00:11:01.660 So, yeah, I mean, if you're being asked 308 00:11:01.660 --> 00:11:03.710 to develop something on the internet 309 00:11:03.710 --> 00:11:05.620 where it's just like a little phone tool, maybe, 310 00:11:05.620 --> 00:11:08.790 for one team, there's probably not a whole lot of point 311 00:11:08.790 --> 00:11:09.820 in over-engineering that 312 00:11:09.820 --> 00:11:12.970 and building some huge horizontally scalable system, right? 313 00:11:12.970 --> 00:11:14.800 Maybe a simpler one is okay. 314 00:11:14.800 --> 00:11:17.610 Maybe vertical scaling is okay in that instance. 315 00:11:17.610 --> 00:11:20.460 But the truth is, for most of these system design interviews 316 00:11:20.460 --> 00:11:22.570 at the big companies, that's not the sort of thing 317 00:11:22.570 --> 00:11:23.830 they're gonna ask you to design. 318 00:11:23.830 --> 00:11:25.740 They're gonna ask you to design YouTube 319 00:11:25.740 --> 00:11:29.290 or design Google, design some massive system 320 00:11:29.290 --> 00:11:30.910 where you need to have that scalability. 321 00:11:30.910 --> 00:11:33.460 So usually, it's a safe bet that you want to go 322 00:11:33.460 --> 00:11:35.270 with a more horizontally scaled, 323 00:11:35.270 --> 00:11:39.500 horizontally partitioned architecture there instead. 324 00:11:39.500 --> 00:11:41.140 So let's dive into that in more depth 325 00:11:41.140 --> 00:11:45.340 in our next section here, but big takeaway here, 326 00:11:45.340 --> 00:11:47.310 vertical scaling just means that you're throwing 327 00:11:47.310 --> 00:11:49.040 bigger machines at the problem. 328 00:11:49.040 --> 00:11:50.620 Horizontal scaling means you're throwing 329 00:11:50.620 --> 00:11:53.140 more machines at the problem and distributing the load 330 00:11:53.140 --> 00:11:55.180 throughout those different machines, okay? 331 00:11:55.180 --> 00:11:57.960 That's the main thing to take away from this lecture.