An Introductory Guide to System Design for Frontend Developers 👩‍💻

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 -

• System Design
• Product Sense
• UI Architecture
• Machine Coding or Component Design

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 -

• High-level design (HLD) - designing a complete system
• Low-level design (LLD) - designing a specific component from the system

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 -

• Requirements (HLD)
• Scope (HLD)
• Tech choices (HLD)
• Component architecture (LLD)
• Implementation details (LLD)

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:

• Functional - These requirements are basically what is explicitly expected from your system. This would include features and functionalities that should be included in your system.

  Eg: An e-commerce website should have authorisation and authentication for users, adding items to a cart, payment gateway configured, etc.

  
  

• Non-functional - These consist of features that aren't explicitly asked for but are implicitly assumed that your system should be able to do. Eg: mobile/desktop compatibility, accessibility, performance, responsive/adaptive, design system etc.

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 -

• An e-commerce website like Amazon
• Video streaming platform like Netflix
• Pinterest board

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

• Typeahead or Autocomplete search component
• Payment gateway
• Data table

Things to keep in mind

• You can choose to either use a framework or Vanilla JS while talking about the implementation details

  
  

• Very little, to ‘none at all’ coding is expected in a System Design interview round as the aim is to find out how you think and if you consider multiple possibilities when you think about a problem

  
  

• It is extremely important to think out loud while making any assumption or decision about your system/component

  
  

• Do not jump directly to designing the system. First, think about it for a couple of minutes and then ask all the relevant questions before starting your process

  
  

• In the case of High-level design, the focus is the system or module. Although, you should mention the components or features you’d like the system to have. But with Low-level design, the focus should be on the component alone.

  
  

• Lastly, always treat the interviewer as a stakeholder and ask questions while designing your system/component in case of any doubt or confusion. Always better to ask than assume 😉

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

• What is Front end system design? Learn how to ace a frontend interview

• Cracking Frontend System Design Interviews | Front-end System Design | 💪Chakde System Design

• System Design Guide for Front-end Developers