Best Frontend System Design Interview Cheat Sheet 📒

 

A structured approach is very important when appearing for a frontend system design interview since most of the frontend system design can be overwhelming for an hour-long interview.

This most comprehensive Frontend System Design cheat sheet will provide a guided framework-driven approach to handle any Frontend System Design Interview. This will help you to ace this interview by completing the important part of the system design within time limits. Let's start

Topic Covered

1. Know About Interview
2. RADIO Framework for Frontend System Design
3. Requirement Gathering
   • Functional Requirements
   • Non-Functional Requirements
   • Scoping
4. Architecture Approaches
   • Frontend Architecture
   • Data fetching protocols
   • Data fetching techniques
   • UI & Data Rending Approaches & Mechanism
   • Enable support for Accessibility, i18n & Offline Support
5. Data Handling
   • Data Entities
   • Data Store (like Redux)
6. Interface (API)
7. Optimizations
   • Performance Optimizations
   • Network Optimizations
   • Rendering Optimizations
8. Extended Topics
   • Security Considerations
   • Observability
   • Testing & Automation Considerations

1. Know About Interview

This interview mostly focuses on how well you can capture requirements and translate those requirements to design a system.

1.1 Type of question you can expect

Primarily there are 2 types of questions you can expect

1. Complex component frontend system design
   Examples - Grid component, Notification, Auto Complete/Typeahead search
2. Application frontend system design
   Examples - Facebook News feed, YouTube player, Sprint Board etc.

1.2 What is the interviewer's expectation?

There are 3 major expectations in the frontend system design interviews

1. Able to drive & design the whole frontend system from open-ended requirements.
2. Knowledge about the frontend system best practices Examples - when to use Debounce or throttling, Virtualization, Intersection Observers etc.
3. Able to explain tradeoffs between various approaches while building frontend system design Ex - REST vs GraphQL, where to store data local, session or IndexedDB

2. RADIO Framework for Frontend System Design

Best Framework to follow for frontend system design - “RADIO”

R - Requirements

Clarify functional & Non Functional requirements. Define the scope of the front-end system design.

A - Architecture

Which architecture to follow - Monolith or Micro-frontend or Mono-repo

D - Data Entities

How the application data look like and the entity's relationship

I - Interface APIs

API Interface to interact with various functions of the system this can be REST API, GraphQL interface or functional interfaces.

O - Optimizations

Various optimizations to make frontend applications more performant & scalable, primarily “Network Optimizations”, “Asset Optimizations” & “Rendering Optimizations”.

In the rest of the notes we will deep dive into each of the RADIO framework steps one by one, let's start 👇👇👇

3. Requirement Gathering

Any frontend system design round starts with requirements gathering, and generally, 2 types of requirements should be gathered as part of this stage.

💡 It is important to rather focus on remembering requirements, we should focus on the right questions to generate the functional and non-functional requirements.

3.1 Functional Requirements

The functionality the system will provide to the end users to fulfil their use-case. for example - for an e-commerce website, displaying catalogue items, and searching through the catalogue is the functional requirement.

❓Question: What user will the user use the system for? or what capabilities the system will provide to the users?

We can derive functional requirements via 2 approaches

1. Page-wise functional capabilities
   Example: E-commerce system design: Home page, login page, user page, catalogue page, search page, details page, checkout page, payment page
2. Module-wise capabilities
   Example: E-commerce system design: user module, catalogue module, checkout module, product module.

3.2 Non-Functional requirements

All the requirements which are essential to make a frontend application more robust, performant, scalable, and secure are considered non-functional requirements.

❓Question: Who are the users?

1. Multiple roles - RBAC support
2. All age group support requires “Accessibility support” - Keyboard navigation, screen reader support
3. Across the globe, support requires “Internationalization” - language, currency, date format

❓Question: How will they going to use the system?

1. Device support - Desktop, tablet, mobile phones, screen readers, slow network
2. Offline support required - using service workers
3. PWA (Native support) - direct launch, push notifications, offline access
4. Personalization - The system should be configurable for personalization
   • Dark Mode preferences
   • Notification preferences

❓Question: What kind of experience do we want to support in the system?

1. Performance - The system should be performant
2. Security - The system should be secure from unauthorized or unauthenticated use
3. Scalability - Use scalable UI design patterns, like virtualization, pagination, lazy loading etc.
4. Graceful Error & Exception handling
   • Server errors/exceptions
   • Network error/exceptions
   • User error/exceptions
5. Extensibility - How easy is it to extend the system and add new functionalities

3.3 Scoping

It is a very important step after requirement gathering since we know most of the frontend system design interviews last for around 45 min to 1 hour. In this limited time, we can not dig deep into all the functional and non-functional requirements.

This step helps you to discuss all the functional and non-functional requirements, and come up with a scoped list of requirements on which you will going to focus in the rest of the interview

Example

Let's say we need to build an e-commerce application like Amazon, and we have mentioned user management, authorization & authentication, and role-based access as a functional requirement. These kinds of requirements are common in most of applications, so In the scoping step, you can discuss and remove these kinds of trivial common requirements and focus on more specific requirements related to the application design.

4. Architecture Approaches

4.1 Frontend Architecture

There are 3 major approaches for architecting frontends

Micro-Frontends

1. Popular ways to implement using IFrame, Web Components, Module Federation
2. Vertical slicing of the application development as part of micro-frontends.
3. 2 primary ways of implementation - Build Time integrations & Run Time Integrations.
4. Provide better separation of concerns
5. Can use different tech stacks for developing front-end applications.
6. Different teams can work on different micro-frontends in different delivery cycles
7. There is no need to build the whole code every time, only an updated micro-frontend needs to be built and released.

Monolithic frontend

1. All the teams need to work on the same code base so hard to scale
2. Adding new functionalities can be challenging along with the existing code
3. Required to build the whole code for any change in any part of the application
4. Any kind of bug fixes or change in tooling will impact the whole code base and create regressions
5. It is very easy to start, and suitable for minimum functionality and less frequent releases.
6. Bound to use the same tech stack across the frontend side, like the framework.

Mono Repo

1. Primarily suitable for projects where existing logic/framework/ feature needs to be shared with new projects so that they do need not to reinvent the wheel.
2. Build and release processes are generally slower than counterparts, but saving time from reusability of logic can justify this slowness.

4.2 Data Fetching Protocols

There are 4 Major Protocols for Communication between client-server or between services.

1️⃣ REST APIs

1. Simple to use, No additional client required like GraphQL
   Out-of-box caching is available
2. Multiplexing, header compression, and server push are available through HTTP2
   Statelessness between requests.
3. It is best suited for external APIs because of widespread community support.
   Typically returns JSON or XML.
4. Cons - More bandwidth consumption, requires multiple calls
5. Cons - Under-fetching and Over-fetching issues

2️⃣ GraphQL (From Facebook)

1. Pros - Fetch what exactly needed, No under-fetching, or Over-fetching
2. Pros - Can use HTTP2 benefits, and is suitable for complex structures.
3. Cons - Additional client is required like Apollo
4. Cons - Out-of-the-box caching is not available

3️⃣ gRPC - Google Remote Procedure Call (From Google)

1. Suitable for communication between internal services
2. HTTP/2 usage for transport
3. Support fast bi-directional communication.
4. Use protocol buffer (aka ProtoBuff) for the communication than JSON
5. Suitable when strong typing is required across different languages (services developed in different languages like Java - Node).

4️⃣ tRPC - TypeScript Remote Procedure Call

1. Focused on Client Server communication based on TypeScript
2. Utilize typescript for type safety across the communication
3. tRPC provides GraphQL-like dynamic schema but with more simple approach than GraphQL.
4. It can work with typescript-based tooling like Node, React etc

4.3 Data Fetching Techniques

4 Common Approaches for Data Fetching

1️⃣ Short Polling - Using REST protocol

• Stateful communication, Easy to load balance
• Simple to use with REST
• Cons - More bandwidth utilization, more load on the server
• Cons - This can result in a slow UI experience in case of polling a large chunk of data frequently.

2️⃣ Long polling

• Client sends requests frequently but sever sends a response when there is a new/updated response available.
• Stateful communication, Easy-to-load balance.
• Better than short polling, and uses less bandwidth than short polling.
• Server-side logic is required to enable long polling.

3️⃣ Web Sockets - using ws/wss protocol

• Stateless persistent communication.
• Enables Bidirectional event-driven communication
• Pros - Real-time communication - Best suitable for apps that require live interactions like chat, collaboration board
• Cons - HTTP2 support is not available
• Cons - Required more resources and Load balancing is hard
• Cons - Cause issues with firewalls & proxies

4️⃣ Server-side events

• Send data from server to client, best suitable for notifications, live charts etc.
• Pros - Push data from server to client
• Supports HTTP2 capabilities.
• Cons - Only text data supported
• Cons - Only one-way communication happens

4.4 UI & Data Rendering Approaches & Mechanisms

How data and overall webpage render on the client device.

Data Rendering Approaches

DOM-based Vs Canvas

1️⃣ DOM Based

1. Pagination - Page size, page no, offset
2. Virtualization - using libraries like react-window where rather than adding new DOM elements, it uses existing DOM elements with updated content.
3. Infinite Scroll or Infinite load - This can be done using intersection observers.

2️⃣ Canvas Based

1. Relatively harder to implement than the DOM-based approach
2. A large amount of data can be rendered as part of the single canvas DOM element.
3. Accessibility & Event handling is challenging with Canvas and requires custom handling of these cases.

Rendering mechanism

How is the overall webpage delivered to the user’s device? There are 3 popular techniques

1️⃣ CSR - client-side rendering

1. Very little SEO support
2. Navigation between pages is smooth
3. Less utilization of bandwidth - Good for bandwidth-critical devices.

A classic create-react app is an example of client-side rendering, without using any special package to make it server-side. This means only a single base “div” element is rendered and the whole application is rendered within div using JavaScript.

2️⃣ SSR - server-side rendering

1. Very Good for SEO
2. Fast initial load, The server sends the whole page
3. More server-side changes are required to support this.
4. More bandwidth utilization
5. Navigation between pages is smoother than CSR
6. Next JS, or older JSP, ExtJS are the classic example of SSR applications.

3️⃣ SSR with hydration

1. This approach tries to mix both approaches to take advantage of both SSO and smooth internal navigation.
2. Fast static website initial load, and then JavaScript injected to add interaction to the webpage.

4.5 Enable support for Accessibility, i18n, Offline Support

Accessibility

✅ You should cover this part only if you get a “YES” below questions from the interviewer
Q1 - What is the user age group? Do we need special support for senior citizens?
Q2 - Is this a general-purpose application? and expected to be utilized by specially-abled users?

✅ Primary considerations (You should cover the important ones, due to the limited time, otherwise there are many others for vision, hearing, voice & disabilities)
💠 Screen reader support - By utilizing semantic elements, aria-roles and aria-states
💠 Keyboard support - Keyboard navigation support for the Application
💠 Contrast colour support - Support contrasting colours, light/dark theme support.

Internationalization (i18n) & Localization

✅ You should cover this part only if you get a “YES” below questions from the interviewer
Q1 - Does this application have a user base across the borders?
Q2 - Does this application require localization support for multiple local languages
For example - localization can still be applicable in India to support regional languages, along with English.

✅ Primary considerations
💠 Support for the language switch or auto-detect the browser's default language
💠 Which currency to show
💠 Time-zone & date time format support etc.

Offline Access

✅ You should cover this part only if you get a “YES” below questions from the interviewer
Q1 - Does this application work even if there is no internet connection, and will sync as soon as online?
Q2 - How much data support is required for offline access? With the answer to this question, you can decide which type of cashing you can utilize to support offline access

✅ Primary considerations
💠 Implementation of offline capabilities can be achieved through “Service workers”. You can consider making the app a PWA (Progressive web app) where the app will have more capabilities than just offline support.

5. Data Handling

Divided into 2 parts to cover them in depth within the length limit
1. Data Entities
2. Data Store

5.1 Data Entities

What are data entities? how do you represent them?

💠 Data entities represent the building blocks of the data which is required to render the part of the frontend application.
For example - In the News Feed frontend System, define data entities that are required to represent a single newsfeed
💠 Data Entities are similar to Objects (Real-world Entities) in Object Oriented Programming.
💠 Generally it's advisable to use TypeScript to represent the type of the data entities, you can assume these are the kinds of TS Interfaces that you need to design the system.

Example:

Let’s take an example of a complex system like Google Sheets,
here is a glimpse of data entities, (It's not the whole, there can be many more)

cell: {
     calculatedValue: string
     type: TableCellType
     formula: formula
     formatting: [FormatOptions]
     width: number
     height: number
}

type CellType {
     type: enum [NUMBER, STRING, DATE, CUSTOM],
     defaultFormula: formula
     customFormula: String
}

type formula {
    name: string
    expression: string
}

type FormatOptions: enum {
    BOLD,
    STRIKETHROUGH,
    ITALIC,
    …
}

Important Notes

👉 In general, trivial data entities can be skipped after getting confirmation from the interviewer like User, Authentication/Authorization (Role base access), Caching entities etc.
👉 It's important to make sure that using the described entities, you will be able to represent the whole data/functionalities required in step 1 of requirement gathering.
👉 Keep it crisp so that can be practical to cover in 1 hour Interview.

5.2 Data Store

Data Sore is important for easily storing and accessing application state-specific data and API responses. A few examples of data store libraries like Redux, Redux-toolkit, MobX

Follow the below pointers to create a Data Store for an application or component in the frontend system design interview

1. Error Cases: Include Error scenarios, to store as part of the Data Store. In most cases, the error comes from API.
2. Data Entities: Make sure you plan to store all the data entities which have been identified in the previous step.
3. Load when required: In case of pagination or cursor-based data, plan to add the data incrementally as the user fetches the data.
4. Store Normalized Data: Store data entities in Normalized format for quick access through keys rather than looping through the entire array.
   Normalization Example
   

   {
   posts: [
       {
           id: 12758,
           slug: "blogs/mypost1",
           tags: ["concept", "javascript"]
       },
       {
           id: 12698,
           slug: "blogs/mypost2",
           tags: ["concept", "css"]
       }
     ]
   }

   Normalized data for Data Store, Now posts can be accessed directly posts[<id>] 
   

   {
   posts: {
       12758: {
           slug: "blogs/mypost1",
           tags: ["concept", "javascript"]
       },
       12698: {
           slug: "blogs/mypost2",
           tags: ["concept", "css"]
       }
     ]
   }

6. Interface (API)

This step involves designing an API which will fuel the whole application with data from the server

Design the API using the protocol which has been selected as part of Data Fetching Protocols and consider the below points while designing the APIs

API Design

There are 2 parts of the API design - the URL and the response

1. URL - URL should follow the best practices defined as part of the protocol design (like REST or GraphQL best practices)
2. API Response - Design the API response based on the application data store or vice-versa, the response should be extensible and should be loosely coupled with the type of data.

API Versioning

Use API versioning to enable backward compatibility in case of a change in APIs.

Examples: /api/v1/posts & /api/v2/posts

Long List Support

Consider long list support for the API design

1. Pagination Support - There are 2 popular ways.
   • Cursor-based
   • page number-based
2. Filtering - Consumers can filter data on the server side using filter query parameters
3. Searching - Consumers can search text/regex-based search on the server side using filter query parameters
4. Sorting - Consumers can sort on the pre-defined keys on the server side using filter query parameters (asc/desc)

Security

Use required tokens to enable API security, popular ones are below

1. API Key as a query param
2. CSRF token
3. Authorization JWT token - Authorization: bearer <JWT token>
4. Content Policy

Error Handling

Use Failure & Exception handling by adding Error Codes & Error Messages as part of the API response.

{
      error: {
          code: 2374,
          message: [{
               error_message: "Something went wrong",
               error_description: "This error happened due to failure of xyz service."
          }]
      }
      ... rest of the API details
}

7. Optimizations

3 types of optimizations can be done to make frontend applications fast and optimized.

7.1 Performance Optimizations

1. Don’t block main thread: use web-workers for heavy computations, parallel tasks
   • Only for non-DOM manipulation tasks
2. Asset Optimizations
   • JS optimization
     • Async, defer for JS script
     • Minification of JS bundle - webpack
   • CSS optimization
     • Load above the fold - critical CSS first
     • Use rem units
     • Use Naming convention - BEM block__element--modifier
   • Image optimizations
     • Use progressive image - PNG, WebP image
     • Lazy load images using <img loading="lazy/eager" src="" />
     • Use height and width for images - To minimize CLS (Cummulative layout shift) web vital.
     • Adaptive images - using "srcset"

7.2 Network Optimizations

1. Gzip, Compression for assets - HTML, CSS, JS
2. Resource Hinting - Prefetch, preload, pre-connect
3. Rate limit request to server - Debounce, throttling
4. Bundle splitting - load only what you want to consume
5. Optimizing content delivery
   • Content Delivery through CDN
   • HTTP Cache (Using cache-control header)
   • Service Workers - Can be used for caching for faster content load.

7.3 Rendering Optimizations

1. Loaders, placeholders and error state
2. Virtualization (Using Intersection Observer), lazy loading, pagination or infinite scroll
3. Lazy loading and code splitting - Non-critical assets
4. Select SSR or SSR with hydration for better initial load performance

8. Extended Topics

These are the additional topics, which can be covered if explicitly asked or time permits as part of the frontend Sytem Sesign Interview

8.1 Security Considerations

Below are the important security considerations for most applications

1. Authentication & Authorization using SSO, or OAuth2.0
2. Using HTTPS
3. XSS attack - cross-site scripting
   • Encoding input text, and decoding while showing on the page
4. CSRF - Cross Server resource forgery
5. CSP - content security policy
6. CORS - cross-origin resource sharing
7. API Rate limits, to avoid Denial of service attacks.

8.2 Observability

Observability involves the systems and ways to measure the health of the overall system

1. Logging & traceability - Logging error information and other information to debug any issues
   • Success and failure logging
   • Latency logging
2. Analytics
   • Tracking user interactions
   • Page views, observe clicks etc

8.3 Testing & Automation considerations

How to ensure the quality of the application when several team members working on the same code base, and how to avoid regressions. There are a few primary testing & automation considerations like

1. Smoke UI tests - including basic sanity check of the application if things are working as expected like login, page load etc
2. UI automation using libraries like Cypress, Nightwatch, and Puppeteer.