System Design interviews can be a pretty difficult thing, especially as learning it requires actually mostly doing it out in the wild.

It's never easy to be confronted with a whole system, and especially when confronted with the task to design all of it. Most platforms were built over years, with many engineers involved in the process. They all failed at some point, adapted, and overcame the issues. And now, here you are, wanting that one position, and having to design a system all on your own.

I've been a software architect for most of my professional life and have designed distributed systems for some of Europe's largest banks. I've also interviewed several engineers over the years and think that I can help you to ace your next System Design interview.

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 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 will need APIs to:

• Upload and view images,
• To retrieve the feed
• To store and retrieve comments for an image
• To store and retrieve likes
• To manage your profile
• To manage people's followers
• To store and retrieve stories
• etc.

As you see, existing systems are already pretty large, so it makes sense and it's absolutely okay 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:

• Active daily / monthly users
• that being transformed to an estimate about how many API requests/s 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. Because 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, as well. 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 microservice 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 API to retrieve images, 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.

Conclusion

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.

Before you leave

If you like my content, visit me on Twitter, and perhaps you’ll like what you see!