System Design Interview Prep
Unlock System Design Interviews: Step-by-Step Structure Guide 🚀
Let’s be honest — the system design interview has nothing in common with the real-world task of designing a scalable system architecture.
The clock is ticking and within 45 minutes you are supposed to draft a well known large-scale system like Netflix, that took years to design and implement in reality.
As a consequence, even very experienced and capable software architect are likely to fail the interview.
To make sure you won’t suffer the same fate, in this article I walk you through a battle-proven step-by-step guide that already lifted thousands of engineers before you into roles at big tech companies.
The overall structure of every system design interview consists of 6 individual tasks. Of course, the high level system design, what everyone thinks system design is all about — drawing boxes and arrows, is one of them.
But before you get out your virtual pen, there are a couple tasks to complete to prepare you and the interviewer for that central deliverable.
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 suppost to be doing, it’s time to estimate the capacities that are requited 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.
Thanks for reading this article! Curious what’s the most likely questions to appear in your system design interview? Take my quick, free assessment to pinpoint the perfect system design interview prep strategy for you in under a minute!
