Thread by @oliverjumpertz

I've been a software architect for most of my professional life, and system design has always been my bread and butter.

Here are 7 steps that I would advise you to follow to ace your system design interview.

They will bring you further than ever, promised.

A thread. ↓

0. Foreword

As a software architect and tech lead, I had the chance to interview some very bright engineers throughout my career.

I've also interviewed quite a few times myself.

This approach is the one that I would use to design a system.

I highly believe that this approach is the one you should use in your interviews, as it's an incremental and organized workflow.

Your goal is that your interviewers understand what you design.

This enables them to follow along as you design.

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 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?

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,
- 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
- Manage story reactions
- 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 think of or if you should only focus on one 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.

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.

Throw a number in the room which you find reasonable.

In the case of well-known platforms, inform yourself before the interview.

The numbers for Instagram, Facebook, etc., are all out there on the internet.

Regarding numbers, we talk about:

- Active daily / monthly users
- 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 done 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.

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 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.

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 the interview is about.

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.

Common thought can already bring you far here.

If you are really unsure, ask your interviewer.

It's their job to give you hints in such a case.

-> Illustrating entities and data flow

You can use a UML class diagram, draw a box with properties in it, or 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.

5. Draw a high-level design

Most systems only have a few crucial 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 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.

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, which is handled by an internal implementation.

To store images, it needs access to some kind of storage 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 service view, for example.

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.

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.

You don't have to be able to recall each and every disadvantage, but be able to state the most important ones.

8. Thread end

That's it for this thread. 💛

I hope you found something useful in it for you. 🙏🏼

If you enjoyed reading this thread, drop a like, retweet the first tweet, and follow me (@oliverjumpertz) for more content like this.