System Design Primer - What Is This Core Software Engineer Skill?
If you're a software engineer, you have probably heard of the term "System Design" before, particularly when it comes to interviews. As the interviews suggest, system design is an important skill, especially for senior software engineers.
The problem is that system design for interviews and actual system design are two very different things. As the vast majority of software engineering resources revolve around passing interviews, this makes most of the online system design content not very useful when you're actually on the job and building software.
In this article, I'll be covering basic system design concepts at a high-level, breaking down the techniques I used to design real systems for billions of users as as a Meta tech lead and tens of millions of users as a Robinhood tech lead.
What Real System Design Is
To start, it's probably easier to show some examples of what system design isn't:
"Build all of Netflix at a high-level."
"Implement the Twitter home feed."
Spoiler: There is no chance you will do anything close to these exercises at your actual job, even if you go to these specific companies. Netflix has already built Netflix, and Twitter has already built out its home feed.
Actual system design is going to be far more local, especially if you go to a Big Tech company. You will likely be iterating on an existing feature or adding a new, very incremental feature to an already well-defined product. The true definition of system design is any sort of higher-level proactive decision making that improves the quality of the software you're building.
For example, introducing API versioning so older versions of your mobile app won't break when you change an endpoint definition is system design. Knowing how all of Netflix is built from a very bird's-eye view isn't system design: It's just random trivia.
What Makes A System Design Good?
Many software engineers equate good system design quality with how modern a tech stack is and whether or not FAANG uses it. This is completely not the case and is often times the easiest way to have a terrible system design.
The goal of any software is to add value to some users' lives: "Clean code" in and of itself doesn't have any intrinsic value. This makes the true definition of a "good" system design simple: Any technical system that can cleanly provide value for the user has a good system design.
Here are some example attributes of a system with good technical design:
- It is easy to iterate on and add new features
- It is straightforward to debug and root cause issues
- It is fast and performs smoothly for the user
- It is hard to break it with bad code
- It works in all cases, even edge cases
If all of the above are true, it doesn't really matter how simple or "primitive" your technical infrastructure may be: Your system design is good.
If you want to learn more about what good system design is, check out my in-depth explainer here.
How Do You Get Better At System Design?
Reading engineering blogs and books have some value, but they're only going to get you ~20% of the way there tops. At the end of the day, system design is just like coding and software overall: You get better at it by doing. The big mindset shift to make here is to think proactively about how you're going to implement things. Don't just start spitting out code whenever you get a task.
The next time you get a meaty task, write out your approach in broad strokes, without any code. Come up with multiple paths, each with their own pros and cons. Think through the edge cases and try to envision the future iterations the code could take on later. Share this all with your teammates to get feedback, so that by the time you start coding, you have a crystal clear idea of how all the pieces fit together.
For a very in-depth breakdown of how you can get better at system design and measure your progress while doing it, read my in-depth explainer here.
System design is one of the most misunderstood skills in software but it's also one of the most important, especially if you're working for a more prestigious, larger tech company that genuinely cares about its software quality and also works with immense scale. It's not really taught in school and isn't taught well with more traditional e-learning resources, so I really hope this primer gives you a better picture of the space.
If you want to go really deep on system design, watch my 10-part System Design Masterclass Series where I break down an actual feature we built into Taro, which comes with a detailed system design doc that follows the structure I used at Meta and Robinhood.