Mastering the System Design Interview: A Step-by-Step Guide to Success
date
Feb 1, 2024
slug
mastering-system-design-interview-guide
status
Published
tags
System Design Interview
summary
Master system design interviews with our guide. Learn strategies to understand and draft scalable architectures for top tech jobs.
type
Post
probability
Facing a system design interview is akin to being asked to briefly outline how to build a cathedral, armed only with a sketchpad and a timer set to 45 minutes. It's a high-pressure scenario that distills years of architectural evolution—think Netflix or similar tech behemoths—into a mere sliver of time. The gap between this artificial exercise and the real-world process of developing a scalable system architecture is vast.
This stark reality means that even the most seasoned software architects can stumble, their extensive experience overshadowed by the interview's contrived format. But your story doesn't have to end in frustration!
This article is your guide through a meticulously crafted, step-by-step strategy that has propelled thousands of engineers into coveted positions at major tech firms.
A typical system design interview unfolds across six distinct tasks. Yes, the quintessential activity of sketching boxes and arrows to represent system design does play a starring role. However, several critical steps precede this moment, preparing both you and the interviewer for the pivotal task ahead. Let's demystify this process together, ensuring you're not just ready but primed to excel.
1. Requirements Engineering
Best, you start off with requirements engineering, to identify what's the functional features you and the interviewer consider relevant for this interview and what's the system's attributes required to deliver an outstanding user experience.
Not every systems needs to be consistent across all nodes. For social media platforms like Twitter for example, it's fine the show feeds that are inconsistent cross multiple users, but the same level of inconsistency would be a complete show stopper for file sharing and real-time collaboration apps.
2. Capacity Estimation
Once you know what your system is supposed to be doing, it's time to estimate the capacities that are required to deliver on that goal.
You have three key metrics that are relevant
- throughput
- bandwidth
- storage
Throughput is commonly expressed in requests per second. It describes how many requests the system needs to handle in order to provide its core value proposition. You normally distinguish between read and write requests.
Netflix for example needs to handle plenty of read requests as every user client fetches a couple of MBs every minute to ensure a consistent and buffer free streaming experience. While in comparison very few write requests are send as only Netflix employees upload new movies.
Bandwidth describes how much data needs to be send over the network per second. Here both read and write requests matter and especially the size of each request.
Last but not least you should estimate the storage capacity your system needs to support its main purpose. Typically you estimate for the time horizon of 5 years. You can imagine, Netflix needs plenty of storage space while a URL shortener like TinyURL only stores a couple of bytes per link.
3. Data Modelling
In the next step, my approach diverges from the advice you normally see on the internet. I highly recommend to continue with getting a feel for the system's data first before defining any APIs. This step is commonly called Data Modelling. Here you outline the different entities, attributes and and relationships you need to implement the features defined before.
The trick here is to not even try to create fully fleshed out Data Schema, as you won't have the time anyway and a meaningful design for the large scale systems discussed in interviews, won't only rely on a single relational database anyway.
So save yourself some time and only go into details deep enough to make up your mind on which databases would be a good fit and how to overcome the scalability concerns of SQL databases , as most likely some portion of your data will still end up in a relational database due to their strong consistency guarantees.
4. API Design
Just now, after gaining a lot of clarity it's reasonable to define a couple of API endpoints that expose the functionality required for the features you defined previously during the requirements engineering.
Best you limit your initial design to function name, input parameters and the response. But prepare to also talk about URL strings, HTTP Methods and response codes.
5. System Design
With these 4. preliminary steps complete. It's time to draw the actual high level architecture. Here it's important to first focus on the core value proposition of the system, the one reason why it even exists and then add the support features to make it convenient to use.
For Netflix that mean to first draw the streaming portion of the system, including the video upload and only then add any search or recommendation features you have planned for.
Best in class engineers reference the APIs they defined before and comment on the estimated capacities as well.
6. Design Discussion
Last but not least, it's time to critically asses and review your own design in the design discussion step. Best its yourself who points out bottle necks and suggest possible improvements.
It's also likely that you get into more in-depth discussions on individual components and how their internals work. Here is where you finally can shine with your in depth knowledge and experience of system architecture gained in the wild! For all previous steps, systematic and structured preparation is King.