My 7-Step Process to get through any System Design Interview
My 7-Step Process to get through any System Design Interview
The best way to design a system, and to impress your interviewer(s)
Let’s talk about system design, or better: System Design Interviews. I know that many tech interviews still consist of rounds and rounds of technical discussions, trying to figure out what you’re capable of. I also know that these processes usually suck because there are better ways than confronting you with two to three employees of a company who try to assess your skills.
Still, these interviews exist, and being somehow prepared for them doesn’t hurt. Sometimes, it’s the company of your dreams that still uses such processes. In these cases, just applying somewhere else is no choice.
To make your life as easy as possible, and also give you a process that you can use outside of interviews (to design systems yourself), I want to share my personal 7-step process to design any system with you. It’s the process I still use when confronted with such interviews, and it’s the same process I use when I have to interview applicants at the senior staff level and upwards (at some levels, you want to make sure an applicant knows their craft), and design systems myself (of course).
Ready? Let’s get into it.
Step 1 - Clarify The Requirements
Ask questions and a lot of them.
Try to find out what exactly the interviewer expects from you.
Try to narrow it down as far as possible to the exact scope of the problem. Even if the question is to (re)design an existing system, ask.
The amount of questions you could ask is nearly endless, but here are some ideas for you:
Are there multiple frontends (App + Website + more)?
Are there regulatory requirements?
Do we need our own auth, or can we leverage an existing one (like login with Facebook/Google, etc.)?
Are there other consumers than the known clients planned for our APIs?
Do we need third-party integrations?
Do we want to incorporate a data lake for analysis?
Any requirements on data consistency?
Step 2 - Define System Interfaces
Define all APIs that the system will (probably) need. Explain what each API is for as detailed as possible so the interviewer can jump in and tell you if you got a requirement wrong.
If you got something wrong, no problem, adjust accordingly!
To give you a general idea, take a platform like Instagram for example which needs APIs to:
Upload and view images,
Retrieve the feed
Store and retrieve comments for an image
Store and retrieve likes
Manage your profile
Manage people's followers
Store and retrieve stories
etc.
As you see, existing systems are already pretty large, so it makes sense to ask your interviewer if you should really lay out everything you could possibly think of, or if you should only focus on a part of the existing system.
Illustrating System Interfaces
You can, for example, start with a use case diagram, which is a great way to identify and showcase possibly needed APIs.
Step 3 - Estimate The Scale Of The System
Give estimates to the scale of the system and communicate them clearly. Once again, if you got a requirement wrong, the interviewer can tell you, and you can adjust. If not, the interviewer can better understand your design decisions.
You don't need to give an exact estimate here, simply throw a number in the room which you find reasonable. In the case of well-known platforms, inform yourself prior to the interview. The numbers for Instagram, Facebook, etc, are all out there on the internet.
And regarding numbers, we talk about daily / monthly active users being transformed to an estimate of how many API requests/s (or minute) your system should be able to handle
If you interview at an organization that has such a well-known platform, you can impress your interviewer if you have the numbers at hand. This shows that you are really interested in the company and have made your homework.
You don't have to memorize those numbers exactly, it's not even about 1 or 2 million more or less, but you shouldn't be off by hundreds of millions. Being off by such a large amount could lead to design decisions you would not have made otherwise.
Step 4 - Define The Data Model
Define the data model of the system, and define how data flows. Ask how detailed this step should be, and if your interviewer requires it at all.
If it's required, also explain and maybe visualize how data flows between the components of the system.
Leverage relational models where applicable, but don't forget that there are other types out there, as well, like documents, graphs, and many more. Try to use the most appropriate ones for the entity at hand. It might, for example, make sense to leverage graphs for friendship-like relationships or for follower relations. If you find such a graph model fitting, use and model the entity accordingly.
Don't forget to lay out how the entities move through the system, like for example: The feed service fetches a user from the user service. The user entity thus travels from the user service to the feed service, and maybe even further.
You don't have to come up with the exact solution that the engineers of an existing platform came up with. That's not what an interview is about. Simply add the properties you may find fitting, and which are just enough to fulfill the requirements.
Your users, for example, will most likely need a forename, a name, an ID, an email address, and so on.
Illustrating Entities And Data Flow
You can use a UML class diagram, draw a box with properties in it, or simply list the properties of an entity to describe the data.
To illustrate the data flow, you can use simple illustrations to showcase how the data flows for certain operations.
Step 5 - Draw A High-Level Design
Most systems only have a few very important components that make up the core of the system. Try to identify them and draw boxes for the five most important ones, and visualize their interactions. Especially in modern micro-service environments, services communicate with each other (a lot!).
If service A needs some data that is managed by service B, you already have two boxes and one arrow to draw to illustrate that communication.
Remember: If you have already modeled the data flow of certain entities, reuse this information here.
Illustrating The High-Level Design
Once again, a simple illustration with some boxes and some arrows, including descriptions, is enough to showcase the design you have in mind.
Step 6 - Design Components In Detail
Explicitly ask if you should focus on specific components for this step. If not, choose the three most important ones and visualize/explain how they should work and what they should do in detail. A good interviewer will guide you.
Take an image service, for example, that is one of the core components of an Instagram-like system. It offers an API to retrieve images, for example, which is handled by an internal implementation. To store images, it needs access to some kind of storage, which is handled by another internal implementation. Lay all that out, draw diagrams to illustrate your ideas, and help the interviewer understand what you are designing.
Illustrating Detailed Components
You could try to resemble a UML component diagram to illustrate a detailed view of a service, for example.
Step 7 - Explicitly State Bottlenecks
Every system and every design has its limits. If there are bottlenecks in your system (and there will always be), state them explicitly. Give detailed explanations about what affects them, and how you could mitigate them.
This step requires the most knowledge about the components you used to design your system. You'll have to know, for example, when relational databases fall behind NoSQL storages noticeably, or in which situations certain message brokers are not the best choice anymore.
Maybe a relational model was good for the anticipated scale of the system, but migration becomes a pain at some point? You can be pretty creative in this step, but once again, you need to know the advantages and disadvantages of components and also the design principles you built your system upon. You don't have to be able to recall each and every disadvantage, but be able to state the most important ones.
Sometimes interviewers will also jump in and give you hints or state a bottleneck they found explicitly. That's your chance to discuss it with the interviewer and find a solution together.
Those 7 steps listed above can be a guide for you to get through a system design interview. They will support you to design a system in a structured way, but they won't obviously help you to ace the interview automatically. That's up to your skills, creativity, and imagination.
From my very own experience, I never expected candidates to come up with a solution that you could implement right away and that would work flawlessly afterward. For me, the system design interview has always been more of a creative and structured brainstorming session, in which I get to know the candidate's ability to design systems and recall important traits of certain components better.
What I usually found pretty helpful for me and all candidates, though, was exactly that structured approach. Starting from the very beginning, slowly going deeper and more in-detail. This way candidates can structure their thoughts better and I am able to follow along better, which is a win-win situation.
You have (finally?) come to the end of this issue, so let me tell you something:
Thank you for reading this issue!
And now? Enjoy your peace of mind. Take a break. Go on a walk. And if you feel like it, work on a few projects.
Do whatever makes you happy. In the end, that’s everything that counts.
See you next week!
- Oliver