Backend System Design

Making Trade-Offs Exercise

Jem Young
Netflix
Backend System Design

Lesson Description

The "Making Trade-Offs Exercise" Lesson is part of the full, Backend System Design course featured in this preview video. Here's what you'd learn in this lesson:

Jem instructs students to consider trade-offs in system design, prioritizing properties like consistency and availability across applications such as banking apps, URL shorteners, and online stores. He emphasizes weighing decisions carefully, understanding requirements, and acknowledging inevitable failures in distributed systems.

Preview

Transcript from the "Making Trade-Offs Exercise" Lesson

[00:00:00]
>> Jem Young: OK, this is more of a fun, fun collaborative exercise. Let's talk through this together. So let's make trade-offs. Two of these we've already thought about, so this should be easy, right? I think we've even said them out loud. So if you have to make trade-offs, these are the different scenarios, how do you think about them? So let's start with the banking app. What are the two properties we have to prioritize?

[00:00:26]
I think we talked about that, this one, we did. Consistency. Yeah, consistency and failure tolerance. Much more important than availability. You ever get those notifications that your bank will be offline for some scheduled maintenance or something like that? Yeah, I have no idea what they're doing, I don't know, rectifying databases or laundering money, something like that. But it's more important to be consistent in a banking app than it is to be available all the time.

[00:00:59]
What about a link shortening service? What's more important there? Availability? Why? Has to be able to connect people with the short code to the destination URL. It's the core, it's the meat and potatoes of it. Yeah. Everybody agree with that? It's tricky though, isn't it? It's tricky because you're like, no, it should be consistent. But CAP theorem tells us we can't have all of it, so we have to pick one.

[00:01:31]
That's what makes this really difficult and it's subjective too. You can argue the other way. I'd say, no, my link shortening service, it's critical. A lot of people depend on that. Trying to think of some dependency. It's linking to a concert and there's a lot of money on that because we have a marketing team for, uh, who's popular now, Bad Bunny. I don't know. Bad Bunny concert and we're dependent on your link shortening service.

[00:01:57]
So it needs to be consistent because we change those URLs all the time. Everybody needs to have the same one because we have these hype marketing pushes. I don't know, maybe I'm throwing that out there. All right. What if we're building an online luxury banana store called Totally Bananas. What's most important there? We said this one earlier. See, these are patterns you're going to pick up. Probably availability.

[00:02:31]
If bananas are that important to you. What are people, if it's a store, what are we doing? Oh, transactions. Yeah, and transactions you want. Consistency, yeah, yeah, you see the patterns. If we just threw CAP theorem at you, you'd be like, OK, that sort of makes sense. But then you think about it a little bit more, you're like, OK, yeah, what's most important here? OK, good news. Great news. Our to-do app is taking off.

[00:03:00]
It's huge. It's amazing. You know, it's a monster. It's on the cover of Forbes. I don't know how an app does that. But now we have a critical medical team using our to-do app for some reason, for critical things in a hospital. What's most important here? Availability and probably consistency. Can't have both. Well if it's available, the data is updating real time quickly, so if there is a partial.

[00:03:37]
Uh. If someone sees data that someone else didn't see, basically but it updates, it doesn't really matter because it's just updating, I would assume pretty quickly, but I just assume that, so. I mean, that's what we talked about, what are the questions we ask, what are the assumptions we're making. How quickly is the data updating? Yeah. And how often does it need to be read? So what do you all, what's the general consensus?

[00:04:07]
Consistency, availability? Like it depends on specifically what medical items they're doing. Like if you could do like. If you could cause an overdose because you gave something twice. That's a big deal, but if you're just like, oh, I have to make sure they go to the bathroom, like they can go to the bathroom twice, it's not a big deal. I'm going to throw out there consistency because I'd rather people see the right things to do than anything to do.

[00:04:38]
If they're sharing a list. I want to see the wrong task. I'd rather them see only the right tasks. I'm happy to be wrong. Unless it's like a super fast paced emergency team that needs to go super fast. There really fast. It could be either. It depends. It's about the choices you made and assumptions that you wrote down leading up to this, but not an easy one. You have to make a hard choice here. My leaning, my leaning is availability.

[00:05:15]
Just having the system up in general is better than something that's slightly out of date because we can't guarantee full consistency all the time, but we can guarantee eventual consistency. It will eventually update. And these tasks probably aren't changing too often, so eventual consistency is good enough. It's not like people are changing tasks in real time, too often. But that's, these are based on my assumptions and my thinking, you may think differently.

[00:05:48]
And you design a system differently around that. Alright, easier one. Social to-do app. Friends share a list for a party. Consistency or availability? Probably say availability, especially because if it's social, if there's like something that's super pressing and like there's some disagreement, they could probably just text each other and just like get it, like talk it over that way. Yeah. When I think of a social app.

[00:06:17]
I'm thinking what we talked about earlier, reads versus writes, probably more reads than writes, so I'm going to bias towards availability. Just needs to be up and running so people can access the list. So if there's a bingo card for part one of this course, it would be trade-offs. Everything's a trade-off. You have to decide, you have to use your intuition, and that's, again, what makes system design really tricky.

[00:06:46]
It's not a binary yes or no, most of the time. It's, you know, what are the assumptions making leading up to it. Kayleigh said earlier, calling your shots, that's important. Here's what I'm doing and here's why. Cool, I as the interviewer now understand where you're coming from. Maybe I have a different perspective, maybe my system diagram looks a little different, but in the end. Oh yeah, it's correct, because all the requirements you're trying to do, you hit them, even though it came out a little bit differently.

[00:07:13]
That's OK. So the takeaway on CAP theorem, because you'll hear this and then you'll be like, what does this mean? We know that failures will happen. What did Forrest Gump say on the back of the bumper sticker? Stuff happens, um, something different, a little more profanity, but failures are going to happen. You can't get around that, impossible. Unless you have one server, which is not the scope of distributed system design.

[00:07:40]
So you have to decide, is it important to show the latest data or is it important to be up more? Yeah, there is no perfect system. It doesn't exist. We can get close with a lot of technology. We can get eventually consistent. But we can't have all of it. It's difficult. It's very difficult.

Learn Straight from the Experts Who Shape the Modern Web

  • 250+
    In-depth Courses
  • Industry Leading Experts
  • 24
    Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now