Let me start with a confession - I have been terrified of System Design interview rounds for the longest time! Havenโ€™t given a lot of them but the couple that I have experienced have been nerve-wracking. I also remember ending the interview call feeling disheartened and low on confidence ๐Ÿ˜ž

After procrastinating the learning, I finally decided to overcome my fear and get serious about it.

Hence my journey of researching online material started - turns out there is a LOT of it (which I again found daunting ๐Ÿ˜ตโ€๐Ÿ’ซ). So I turned to Youtube to watch some introductory videos before I read some blogs about the topic.

At the end of this article, Iโ€™ve attached some interesting material.

Letโ€™s get started by first understanding why we need to know about System design.

Why System Design?

Letโ€™s start by talking about why we, Frontend Developers, are even expected to know about System Design. I mean System seems like a more Backend topic, and well Design is something for a Designer to think about, isn't it? ๐Ÿคทโ€โ™€๏ธ

Ummm no, fortunately or unfortunately not ๐Ÿ™ƒ

The line between these roles gets blurry from time to time and hence it is necessary for a Frontend Developer to know about developing a scalable and maintainable system from scratch. It would also be very helpful for a Frontend Developer to understand a system's architecture in order to identify issues or bugs with it before they become too costly and time consuming to fix. This would in turn increase confidence in the performance and correctness of the system being built.

If you know whatโ€™s going on under the hood, youโ€™re more likely to build solutions that are better suited to the needs and limitations of your system.

Hence irrespective of your expertise, knowing about System Design would make you a more well-rounded engineer.

What is System Design?

Technopedia describes it as follows -

System design is the process of defining the elements of a system such as the architecture, modules and components, the different interfaces of those components and the data that goes through that system.

A System Design round can be described differently depending on the job profile (Business, Product, Design, Frontend, Backend, Full-stack) you have applied for -

Even though their naming convention is different, their base is the same and they differ only on the focus area.

Broadly we can classify system design into 2 parts -

The aim of a System Design interview is basically trying to understand if you, as a candidate, can visualise a system/component from scratch. It is expected that you think about the requirements, features, and constraints of the system.

I would recommend following the below plan to cover all the required topics -

1) Requirements ๐Ÿ“

These are the requirements of your system. Here you should focus on determining the capabilities and shortcomings of your system.

This topic can be further categorised into 2 parts:

2) Scope ๐Ÿ”

It would be practically impossible to completely design a system in the limited duration of an interview. Hence this part focuses on prioritization of the requirements and features that you listed in the previous section. Here you should focus on some of the most important module-level (system-level) or feature level (component-level) functional requirements. Also, focus on the must-have non-functional requirements. Going forward, these would be the requirements of your system.

3) Tech choices โš’๏ธ

Here the focus should be to finalize the tools and technologies the system would be developed with. Eg: library/framework, state management, 3rd party packages, build tools, etc.

4) Component architecture ๐Ÿ—‚๏ธ

Since this step is part of component or low-level design, we should consider the component hierarchy, folder structure, data sharing, routing, etc. for our specific component.

5) Implementation details ๐Ÿš€

This step again focuses on the component level and its implementation. There are certain topics that you should think about which are very specific to the kind of component you have been asked to design.

Eg: If you are asked to design a search component, you should think about pagination/infinite scroll, debouncing/throttling, search results object, whether you would like your data to be returned through REST or GraphQL, and the structure of your requests and responses, etc.

Some of the other things to keep in mind here would be the reusability of your component (state and props), event handling, data modelling, and API structure.

Examples

For System/Module design, you could be asked to design -

For Component/Feature design, you could be asked to design -

Things to keep in mind

I hope I was able to provide some clarity to the System Design interview round and motivate some of you to read more about it ๐Ÿ’ช

Thanks for reading. Happy hacking and learning! ๐Ÿค“


Resources for Further Learning