Introduction

[00:00:00]
>> Jem Young: my name is Jem Young. I'm a software engineering manager at Netflix, and you're thinking a manager teaching about system design, you must do a lot of coding, and the answer is no, thankfully, just kidding, I love coding, but I don't do a lot of coding as much these days. But you know what I do have to understand is what is happening in the system. That was one of the problems for this course is, you know, these are things I needed to know at one time and things I'm still not good at, things I'm still learning, and I want to teach some of that back to you.

[00:00:29]
But if you're asking, hey, Jem, could you review my PR, the answer is yeah, probably. Will I be good at it? Probably. Should I be doing it? No, no. Any managers in the house? Any other managers? Couple of people silently embarrassed, raised their hand. It's okay, we're all friends here today. I teach a few other courses with Frontend Masters. One is on engineering management fundamentals, things I learned the hard way, becoming a manager, transitioning from being an IC individual contributor to manager.

[00:01:05]
That's a fun one. I did with actually my friend and one of the probably one of the best leaders that I know. I also teach a course called Full Stack for Front-End. We're on version 3 so far. It's 8 hours long, wow, I cover a lot in that course. That's a fun one too. That's more hands on where we're building more, doing a lot more code. I also teach a course on WebAssembly, taught way back in the day.

[00:01:32]
That's a fun one. Definitely more technical, less on the, you know, building UIs and things like that, but it is related. And also taught one, you know, a little while back called Interviewing for Fun and Engineers. This one is more on the idea that we all interview and we all suck at interviewing because we never practice, and how do we fix this? And that's why I teach this course. That's a pretty light one, but it's pretty fun.

[00:01:59]
Let's talk about what we're going to learn today. We're going to start with the foundations of system design. We want to start with scoping. And scoping is honestly the most important part of system design. And you're thinking, no, it's the technology, right? It's the nuances and the details and, you know, arguments about throughput. No, it's the scoping. And this is a mistake that I made, and I failed front-end interviews, or not front-end interviews, system design interviews.

[00:02:32]
I failed 2, 3, 4, a couple of them before, and I couldn't think why, and I always thought, oh, it's because I didn't practice enough. And what I realized was I didn't spend enough time on the scoping part of the system design. I didn't spend enough time thinking about why I'm doing something. I focused too much on memorizing all of the use cases. Design a streaming app, design a chat app, design a ticketing system, design a URL shortener, you know, all the standard cases you run through in system design you've probably heard before.

[00:03:00]
I focused so much on memorizing those that I didn't think enough on, you know, what are the steps to get there to the right step? And we'll talk more about why scoping is so important, but we'll spend some time there. Definitely one of the most overlooked parts when it comes to system design, in my opinion. We're going to talk about system quality. What does it mean to have a quality system? We know it and we see it.

[00:03:23]
If there's an Amazon outage, something with DNS or something like that, and it takes down the internet, that never happens, it never happens. You know, we know a bad system, but what does a good system look like? And what are all the metrics and what are all the aspects that make a good system? Things we know inherently and we've probably felt, but we've never actually laid them out. So let's talk about what makes a quality system.

[00:03:48]
And then we'll talk about scaling. There's different kinds of scaling, and what does scaling even mean? You can scale the number of users, is it a number of requests, is the number of database reads and writes. We'll talk about how do you scale a system up, and that's one of the fundamentals of system design. That's why we're doing it. We'll talk about CAP theorem. CAP theorem is about trade-offs and system design is about trade-offs.

[00:04:17]
And you're thinking, can I have my cake and eat it too? Almost, almost. But CAP theorem teaches us that you can almost have that, but you can't guarantee it. And that's something you have to realize going into designing any system is, what trade-offs am I making? We'll do a quick intro into data storage. We'll spend a lot of time in a second portion of this course on data storage because that's the most important thing when it comes to any system.

[00:04:45]
It's like my professor always said, 90% of your job of what you're doing is reading and writing from a database. And back then when I was in college, I said, and now that I'm older and have done it a few times, now I realize, oh yeah, actually most of what I'm doing is reading and writing from a database. The database may be 10 steps away, but that's really what's happening in the system. That's the most important part.

[00:05:11]
And we'll touch on caching. Caching is extremely overpowered. Almost any good system design is going to have a cache somewhere in there, but where do you put it? What are the trade-offs with caching? Because again, nothing's free. We'll talk on that. Once we get the foundations down, and I consider foundations, we'll say 0 to 100,000 users or requests, how do we get to a million? And when you get to a million, the problems start adding up very differently.

[00:05:43]
You know, those edge cases where it's, oh, this only happens 1% of the time. You know, when you get to a million, what is that, like 10,000, something like that, 100,000, not bad at math. But every edge case comes up when you start working at scale, and that's really the crux of system design is handling these edge cases. Because we can't have failures. No one wants a 90% uptime rate, because that sounds good on paper, but really that means you're down a good portion of the time.

[00:06:08]
And there's things you have to consider when you start working at scale, the security of what you're doing. There's a difference between authenticating someone and authorizing someone. Two different things, but similar concepts often mixed. We'll talk about SSL, HTTPS, the fundamentals of how we make these secure communications. We'll talk about protocols. There's a lot of different protocols, HTTP, GraphQL, REST, when do you choose them, what's the difference?

[00:06:39]
When do you reach for them? The answer is, it depends. And you'll probably get that a lot from me today. Well, Jem, when should I use this? It depends. What I really want us to learn is, depends on what, what's important to you. We'll talk about resilience. Again, it's the edge cases that'll get you. That's really the thing that makes or breaks a really good system design, especially in the interview.

[00:07:02]
What are the edge cases? You can memorize all you want, but until you understand why you're doing something, the interviewer, someone can throw you for a loop. Hey, what happens when this happens? What happens when this database goes down? You're like, um, well, and you're kind of stuck. That's why we want to progressively build up to figure out, you know, how do we handle those edge cases? How do we handle failures?

[00:07:31]
And the one thing we can guarantee that CAP theorem tells us is that failures will happen, guaranteed. So what do you do with them? We'll talk about async workflows. Again, the two things that are overpowered, async workflows and caching. You'll hit a performance bottleneck and you'll think, hmm, what should I do now? I can have a better database, I can add more servers, or I can make it async. It's kind of a cheat code sometimes, but it's not that easy to implement.

[00:08:02]
Again, complexity, trade-offs. We'll get more into data storage. We'll dive into non-relational databases, the object-oriented databases, graph, column, time series. When do you choose these? When you get to millions of requests, then you really have to be, what's the right word for it, circumspect about the database that you choose. So we'll talk more about data storage. And then we'll do some case studies.

[00:08:32]
The tricky part about system design, if you're approaching it from the interview standpoint, is you have to do all this in an hour. You have to get from a prompt, design a chat app, you have to get from there to a full system design including the edge cases in an hour. How do you get there? It's tricky. We'll see why we progressively build up to get to the case studies towards the end. System design is interesting because there's a level of depth you can get to, and it really depends on the role, and we're more focused on the high level, you know, something approachable for someone who's not familiar with system design or maybe from a front-end you've dabbled in the back-end a little bit, but if you're going in for I'm a network operator or a SRE, the interview is going to look very different, and the questions they ask going to be very different.

[00:09:22]
This may help, but I imagine if you're at that level, you're probably not sitting in a system design course, you already generally know about that. But good questions. What's the theme I've been saying the whole time, over and over again? Trade-offs. Everything's a trade-off. Nothing is free. If you're thinking, well, you know, I can just throw more money at the problem, more servers, you can, that's a trade-off too.

[00:09:47]
And that's the thing I want to hammer over and over again is that there are multiple ways to design a system. There's multiple right answers. There's things inherently that you just shouldn't do, but as far as the right answer, it's more ambiguous. And it's about understanding what are the tradeoffs that I need to make and being explicit about that. If I say anything over and over again, it's probably going to be, what's the trade-off?

[00:10:19]
You know, we're going to go from a prompt to a full system that works effectively and works at scale. And here's the thing about system design. Good system design is really boring. It's incredibly boring. You're like, oh, what does this thing do? Oh, it handles billions of requests a second. And you see it on paper, you're like, oh, okay, yeah, it's easy. And this is a mistake I made when studying for system design is, hmm, oh, I'll just memorize the system.

[00:10:47]
I'll memorize what it looks like, how hard can it be? And then I get to the interview and I'm like, what's happening? They asked me something slightly different and now the system's completely different. And I was thrown for a loop. And I want to emphasize this is really hard stuff. It's really hard to be good at system design. You do have to practice, but it's the foundations that matter. And getting here in a short amount of time just takes, you know, understanding the steps.

[00:11:16]
But we're not going to go in a straight line. There are plenty of system design courses on YouTube, general internet, they'll walk you through, like, here's a problem, it's someone on a whiteboard writing things out, and you're like, uh-huh, uh-huh, uh-huh, uh-huh. There's tons of those. I encourage you to check those out. This is a little bit different. We're not going to go from there to here. We're going to go every step along the way.

[00:11:43]
Why? Why are we doing this? The thing that makes me, I think, a decent engineer is, you know, I want to know something. I don't just want to believe it because someone told me, I want to know why. And it also makes me a bad engineer because I tend to go really deep on things that maybe I don't need to go, but what I want you to take away is I want you to know, and not just believe. I want you to know why you're doing something.

[00:12:11]
And that way you can go deeper where you need to because you have the foundations on how to build that up. So, there's something I'd like to say in my team, in my org, we want to crawl, then we want to walk, and then we want to run. A lot of courses that I've seen, it's straight to run. Hey, design a YouTube, straight to run. What do I have to think of? Oh, it's obvious, you know, what's the core entity here?

[00:12:36]
Oh, it's obviously the streaming video and processing video. Those are the hard parts. And, you know, you're just nodding along like, yeah, yeah, yeah, that makes sense now. But why? Why? So we go slow, sometimes frustratingly slow. We're going to take a lot of detours. Like, Jem, I know what the answer is. I know what the next step in the system diagram is. I'm like, yeah, I know you know, but why?

[00:13:04]
That's what we want to get to. So we go slow, we crawl, we walk, and then we run. Tools, if you want to fire them up now. Sketching tools. I use Draw.io. It's pretty powerful. It's going to redirect you to a different place and it's going to look weird. It might prompt you to install it, you can if you want, as an app in your browser, or you can use Excalidraw, which is very straightforward. It doesn't have all the cool shapes that I'm probably going to use that helps me think, but use any sketching or drawing tool that you want to.

[00:00:00]
These will be our primary tools today. And maybe a notepad if you want to take notes or write things down.