mirror
/
front-end-interview-handbook
mirror of https://github.com/yangshun/front-end-interview-handbook.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

[feig] improve intro + framework pages

This commit is contained in:
Yangshun 2025-11-06 19:43:18 +08:00
parent 5d5addba09
commit 5a78b411c9
3 changed files with 269 additions and 124 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

269
packages/system-design/contents/framework/en-US.mdx
View File

@ -6,27 +6,58 @@ social_title: The RADIO Framework for structuring Front End System Design answer
seo_description: A robust framework developed to help you answer front end system design interview questions in a structured fashion.
---
A good beginning is half the battle won. By using the **RADIO framework** to answer front end system design questions, you will already be much closer to acing your interview.
When I (Yangshun) had my first system design interview almost 10 years ago, I fumbled really hard and was going all over the place. Naturally, I didn't pass that interview and I became pretty scared of system design interviews after that. Over the years, I seeked ways to improve how I approach system design interviews and the single biggest change I made was to approach the question using a framework.
In the context of front end system design interviews, the systems you are asked to design tend to be products, so we'll refer to the system as "product" from here on. Start by understanding the **R**equirements, defining the high level **A**rchitecture and the **D**ata Model. Then define the **I**nterfaces between the components in the product and talk about any **O**ptimizations or dive deep into specific areas which require special attention.
I came up with an easy-to-remember mnemonic called the **RADIO framework** to help me remember how to approach system design questions. This article is the **authoritative source about the RADIO framework**.
## What is RADIO about?
1. **Requirements exploration**: Understand the problem thoroughly and determine the scope by asking a number of clarifying questions
1. **Architecture / High-level design**: Identify the key components of the product and how they are related to each other
1. **Data model / Core entities**: Describe the core entities and its data – the fields each entity contains and which component(s) they belong to
1. **Interface definition (API)**: Define the interface (API) between components in the product, functionality of each API, their parameters and responses
1. **Optimizations and deep dive**: Discuss possible optimization opportunities and specific areas of interest when building the product
In the context of front end system design interviews, the systems you are asked to design tend to be products, so we'll refer to the system as "product" from here on.
Start by understanding the **R**equirements, defining the high level **A**rchitecture and the **D**ata Model. Then define the **I**nterfaces between the components in the product and talk about any **O**ptimizations or dive deep into specific areas which require special attention.
- **Requirements exploration**: Understand the problem thoroughly and determine the scope by asking a number of clarifying questions
- **Architecture / high-level design**: Identify the key components of the product and how they are related to each other
- **Data model / core entities**: Describe the core entities and its data – the fields each entity contains and which component(s) they belong to
- **Interface definition (API)**: Define the interface (API) between components in the product, functionality of each API, their parameters and responses
- **Optimizations and deep dive**: Discuss possible optimization opportunities and specific areas of interest when building the product
> [!TIP] RADIO framework is not specific to front end system design interviews
>
> The RADIO framework is not specific to front end system design; it can also be used for back end system design interviews as well. However, you might need to cover additional areas beyond RADIO, depending on the question.
## Using RADIO framework in interviews
RADIO is fairly easy to remember and we're confident that by the time you complete reading this page you'd have memorized what each letter stands for. Use RADIO as a guide and not as a fixed structure that you have to follow squarely.
You **should not** follow the steps in rigid, linear order (Requirements -> Architecture -> Data model -> Interface -> Optimizations). The framework's main purpose is to ensure you cover all critical aspects of the design in a systematic way. In a real interview, the discussion is often iterative and it makes sense to revisit the various aspects as you handle more features. You might even change the architecture entirely along the way and that is alright (if you have a good reason).
The initial step, Requirements exploration (**R**), is the most crucial step to start with. You cannot design a product without first understanding what problems it needs to solve and the target audience.
Once the requirements are set, the next steps form the **core design phase**: Architecture (**A**) and Data model (**D**) are usually addressed early on, as the fundamental structure and state of the application dictate everything else. Interface definition (**I**) naturally follows the Architecture (**A**) and Data model (**D**), as you need to define how the components (like the APIs between client and server, or within components the client) communicate using the data model you've established. Some people prefer to define the Interface (**I**) first before moving on to Architecture (**A**) and Data model (**D**). That's ok and in fact makes more sense for certain products.
Optimizations (**O**) usually come last, as they are a refinement of the complete design. They often involve deep dives into specific non-functional requirements established in step the Requirements (**R**) step.
You should feel free to backtrack and re-address earlier sections based on new insights or interviewer feedback. For example:
- During the Architecture (**A**) phase, if you realize a feature requirement from **R** means your initial Data model (**D**) won't work or isn't ideal, you should immediately go back and revise the Data model (**D)**.
- The interviewer might interrupt and ask for a Deep Dive (**O**) into a component immediately after you mention it in the Architecture (**A**) step (unlikely but possible). You should be prepared to follow their lead. However, do remember to resume from where you left off if you have not completed a holistic design of the product and covered every aspect in the core design phase (Architecture (**A**), Data model (**D**), and Interface (**I**)).
**Write things down.** Interviews are nerve-wracking and it's not uncommon to forget some to cover some things along the way. If you want, you can write "RADIO" somewhere on the (virtual) whiteboard to remind you of the aspects you have to cover. Every now and then, refer to it to remind you of what is left to be covered.
> [!WARNING] Do not force RADIO onto every system design question
>
> While the RADIO framework can be used for the majority of front end system design questions, there are some cases where the framework cannot be applied, especially for some scenarios which are overly-specific and don't require much architecture (e.g. implement a mention feature in Slack).
## Requirements exploration
**Objective**: Understand the problem thoroughly and determine the scope by asking a number of clarifying questions.
**Recommended duration**: Not more than 15% of the session.
**Recommended duration**: Not more than 10% of the session.
System design interview questions are open-ended in nature and are usually vague and under-specified on purpose. **You are required to dig deeper and clarify ambiguities in the problem by asking useful questions.** Treat your interviewer as a product manager you are working with on a new project, ask enough questions so that you know what problems you are trying to solve and what you need to build. In reality, some problems can be solved without any engineering at all!
System design interview questions are open-ended in nature and are usually vague and under-specified on purpose. **You are required to dig deeper and clarify ambiguities in the problem by asking useful questions.** Treat your interviewer as a product manager you are working with on a new project, ask enough questions so that you know what problems you are trying to solve and what you need to build.
No two system design interview experiences will be the same even if you have been asked the same question before. Interviewers have different backgrounds and might prioritize different aspects of the system. Take this chance to find out what they are most interested in and plan your answers accordingly.
No two system design interview experiences will be the same even if you are given the same problem. Interviewers have different backgrounds and might prioritize different aspects of the system. Take this chance to find out what they are most interested in and plan your answers accordingly.
Some general questions you should get answers to before moving on to the next part of the interview:
@ -50,19 +81,19 @@ There are two ways you can get the answer to this question:
1. Take the initiative to list out what you think are the requirements and get feedback and alignment from the interviewer (Preferred).
1. Ask the interviewer directly. However, most of the time they'd want you to define them. Even if they give you an answer, it won't be too detailed.
At the very minimum, your design has to meet the functional requirements. After meeting all the function requirements, move on to talk about how to fulfill the non-functional requirements.
At the very least, your design has to meet the functional requirements. After meeting all the functional requirements, move on to talk about how to fulfill the non-functional requirements.
### What are the core features to focus on and which are good-to-have?
Even after you know the functional requirements, there can still be a ton of small features that make up the large feature. For example, when creating new Facebook posts, what kind of post formats should be supported? Besides the usual text-based posts, should the user be able to upload photos, upload videos, create polls, check in to a location, etc.
Even after you know the functional requirements, there can still be a ton of small features that make up the large feature. For example, when creating new Facebook posts, what kind of post formats should be supported? Other than text-based posts, should the user be able to upload photos, upload videos, create polls, check in to a location, etc.?
You should clarify the core features beforehand and design for them before moving on to the extra features.
Aim to clarify the core features beforehand and design for them before moving on to the extra features.
### Other questions:
### Other possible questions
- What devices/platforms (desktop/tablet/mobile) need to be supported?
- Is offline support necessary?
- Who are the main users of the product?
- Will the app be used offline?
- What are the performance requirements, if any? Performance requirements typically fall under non-functional requirements
The questions above should give you a good starting list but it is by no means an exhaustive list! Different problems will require you to ask domain-specific questions, which we will talk about in the case studies.
@ -71,7 +102,7 @@ You are recommended to write down the agreed requirements somewhere so that you
---
## Architecture / High-level design
## Architecture / high-level design
**Objective**: Identify the key components of the product and how they are related to each other.
@ -79,38 +110,50 @@ You are recommended to write down the agreed requirements somewhere so that you
With the requirements in mind, we can move on to the architecture design proper. Your next task is to come up with a product/system architecture by identifying the key components of the product, how the components interact with each other, and how they are related. Remember to focus on the **client-side architecture**, not the back end.
Diagrams are your friends here. Each component can be represented using a rectangle and your high-level design usually ends up looking like a few rectangular boxes with arrows between them to demonstrate the flow of data. It is also possible to have components within components, in that case, draw the parent using bigger rectangles since they need to fit multiple subcomponents.
> [!WARNING] You don't have to go in order of Architecture -> Data model -> Interface
>
> Think of RADIO as a checklist to ensure a comprehensive answer, not strict linear steps. Lead the discussion with Requirements and Architecture, then be flexible to dive wherever the conversation or technical complexity requires. Some candidates prefer to design the data model first and that's also acceptable and might make more sense depending on the problem.
Examples of components/modules which are commonly found in a high-level front end design:
### Typical components/modules
- **Server**: In front end system design interviews, we can treat the server as a black box and assume it exposes some APIs you can call via HTTP/WebSockets.
- **View**: This represents what the user sees, and it usually contains smaller subviews within it. Can contain client-side only state.
- **Controller**: The module which responds to user interactions and processes the data from the store/model in a format the view expects. This module is not always needed if the application is small and there's not much passing of data between modules.
- **Model/Client store**: Where the data lives. Stores contain data which will be presented to the user via views and stores tend to be app-wide in an interview context. In reality, you can have multiple stores within an application and stores can contain other stores.
Examples of components/modules which are commonly found in the high-level design of front end apps:
- **Server**: In front end system design interviews, we can treat the server as a black box and assume it exposes some APIs you can call via HTTP / GraphQL / WebSockets.
- **View layer**: This represents what the user sees and interacts with and usually contains smaller subviews within it as well as local state. In modern web applications, the view layer is implemented using JavaScript frameworks like React, Vue, or Svelte components. View is responsible for presentation and local interaction state, and that cross-cutting data (shared between multiple views) should live in the store/model layer.
- **Store/model layer**: This is where the application's data and derived state live. The store manages cross-cutting data such as user profile, authentication, app layout state (e.g. whether the sidebar is open), shared domain data, etc.. Modern approaches favor unidirectional data flow and reactive state management, implemented with state management libraries like Redux Toolkit, Zustand, Jotai, or MobX.
- **Data access layer**: The front end interacts with this layer through a typed data access layer (e.g., React Query, tRPC, Apollo Client) that handles fetching, caching, and error management. This abstraction allows the client to consume APIs without being tightly coupled to data origin and associated implementation details. An application can start introducing offline storage with periodic background syncing and this is the only layer that is affected. The other layers above do not care about where the data comes from.
Diagrams are your friends here. Each component can be represented using a rectangle and your high-level design usually ends up looking like a few rectangular boxes with arrows connecting the boxes, labelled with data that flows between them. It is also possible to have components within components; in that case, draw the parent using bigger rectangles since they need to fit multiple subcomponents.
As the term "system design" suggests, we should be focused on "design" and not the "implementation". Unless otherwise prompted, it is acceptable to keep the discussion more abstract and refer to the component in terms of their responsibilities and not have to decide on the actual framework/library to use; the choice usually boils down to a matter of experience and and preference.
> [!WARNING] Not every component is relevant or necessary
>
> It is important to realize that not every component mentioned above will be relevant and necessary for every product. If the product is small in nature (perhaps a single page, or a UI component), it can be acceptable for the data to live within local component state
Other things to consider when defining the responsibilities of components:
- **Separation of concerns**: Components are meant to be modular and serve to encapsulate a set of functionality and data. Consider the purpose/functionality of each component, what data it should contain and how it can service the rest of the system (what it can do for the other components).
- **Where computation should occur**: If some amount of computation is needed (e.g. filtering of results given a search term, calculating the total amount for a cart), should the work be done on the server or the client? There are tradeoffs to each approach and the decision is both product-dependent and context-dependent.
It is important to realize that not every common component mentioned above will be relevant and necessary for every product, it depends on the unique aspects of the product.
- **Where computation should occur**: If some amount of computation is needed (e.g. filtering of results given a search term, calculating the total amount for a cart), should the work be done on the server or the client? There are tradeoffs to each approach and the deciding which depends on both the product and context.
After drawing out the architecture diagram, verbally describe the responsibilities of each component (box in the diagram).
### Architecture example
Example using News Feed
Here's an example architecture diagram for the [News Feed](/questions/system-design/news-feed-facebook) question drawn using Excalidraw.
{/* TODO: Update the diagram */}
![Example architecture diagram](/img/questions/news-feed-facebook/news-feed-architecture.png)
#### Component responsibilities
**Component responsibilities**
- **Server**: Serves feed data and provides a HTTP API for new feed posts to be created.
- **Controller**: Controls the flow of data within the application and makes network requests to the server.
- **Client store**: Stores data needed across the whole application. In the context of a news feed, most of the data in the store will be server-originated data needed by the feed UI.
- **Feed UI**: Contains a list of feed posts and the UI for composing new posts.
- **Feed post**: Presents the data for a feed post and contains buttons to interact with the post (like/react/share/comment).
- **Post composer**: UI for users to create new feed posts.
- **Server**: Exposes HTTP APIs to fetch feed posts and to create new feed posts
- **Store**: Contains data needed across the whole application. In the context of a news feed, most of the data in the store will be server-originated data needed by the view layer
- **Data access layer**: Makes network requests to the server and passes the fetched data to the store. Also serves as a cache for network data
- **Feed UI**: Contains a list of feed posts and the UI for composing new posts
- **Feed post**: Presents the data for a feed post and contains buttons to interact with the post (like/react/share/comment)
- **Post composer**: UI for users to create a new posts
Common free drawing tools that you might be asked to use include [diagrams.net](https://app.diagrams.net/) and [Excalidraw](https://excalidraw.com/). It'd be a good idea to familiarize yourself with these tools beforehand.
@ -130,27 +173,33 @@ Data that originates from the server, usually from a database and meant to be se
### Client-only data
Client-only data, also commonly known as state, is data that only needs to live on the client and does not have to be sent to the server for writing into the database. Client data can be further broken down into two:
Client-only data, also commonly known as UI state, is data that only needs to live on the client and does not have to be sent to the server to be persisted into a database.
- **Data to be persisted**: Usually user input such as data entered into form fields. These data usually has to be sent to the server and saved into a database for it to be useful.
- **Ephemeral data**: Temporary state that lasts for a short time. Common examples include form validation state, current navigation tab, whether a section is expanded, etc. It's usually acceptable to lose these data when the browser tab is closed.
Client data can be further broken down into:
When listing the data fields, it'd be useful to identify what kind of data that field is, whether it's server-originated data or client-only data.
- **Data to be persisted**: Data that usually has to be sent to the server and saved into a database for it to be useful. Examples include data the user enters into forms, profile settings, etc.
- **Ephemeral data**: Temporary data that is acceptable to be lost forever when the browser tab is closed. Common examples include form validation state, current navigation tab, whether a section is expanded, etc.
### Data model example
When listing the data fields, it'd be useful to identify what data type that field represents (string/array/number/date/etc.), and whether it's server-originated data or client-only data.
**Example using News Feed**
Here's a basic example of data model for the various entities using the [News Feed](/questions/system-design/news-feed-facebook) question.
| Source | Entity | Belongs to | Fields |
| --- | --- | --- | --- |
| Server | `Post` | Feed Post | `id`, `created_time`, `content`, `image`, `author` (a `User`), `reactions` |
| Server | `Post` | Feed post | `id`, `created_time`, `content`, `image`, `author` (a `User`), `reactions` |
| Server | `Feed` | Feed UI | `posts` (list of `Post`s), `pagination` (pagination metadata) |
| Server | `User` | Client Store | `id`, `name`, `profile_photo_url` |
| User input (client) | `NewPost` | Feed Composer UI | `message`, `image` |
| Server | `User` | Store | `id`, `name`, `profile_photo_url` |
| User input (client) | `NewPost` | Feed composer UI | `message`, `image` |
You might be thinking "these feed post data looks just like the schema of a database", and you're right! For certain products, the visible data in the UI closely mirrors data from the database. It's common for apps to load a subset of the server data and keeps them in memory (the store) to be presented. As the user interacts with the app (e.g. scroll down the feed and loads more posts), the store merges new data with existing data.
An example of client data that does not resemble database structure is Notion. In Notion, each [block in a document (heading/paragraph) is stored as separate rows in the database](https://www.notion.com/blog/data-model-behind-notion), with fields pointing to other blocks indicating parent/child relationships. To present the document on the page, the client assembles these individual blocks into a tree structure according to their hierarchical relationship.
Depending on how far you progress along in the question and how the requirements have evolved and grown during the interview, you might need to add more fields. It's a dynamic and iterative process.
You might want to write these fields near the components which owns them in your architecture diagram.
In your architecture diagram, you might want to list down these data fields under the component which owns them.
---
@ -158,27 +207,46 @@ You might want to write these fields near the components which owns them in your
**Objective**: Define the interface between components in the product, functionality of the various APIs, their parameters and responses.
**Recommended duration**: Roughly 15% of the session.
**Recommended duration**: Roughly 20% of the session.
With the components and data within each components, we can move on to discuss the interface (APIs) between the components. API is an overloaded term and generally refer to the protocol which software components communicate and request/send data between components. Client and server communicate via network layer APIs (HTTP/WebSockets). Client components generally communicate via functions in the browser runtime. All APIs have three things in common whether they are between the server and the client or between client components:
With the architectural components and data model defined, we can move on to discuss the interface (APIs) between the components. API is an overloaded term and generally refers to the protocol which software components communicate and request/send data between them.
Servers and clients communicate by exchanging messages over a network, following agreed-upon protocols (e.g. HTTP, WebSocket, Server-sent Events) that define how data is structured, transmitted, and understood on both sides.
Within the browser, client components generally communicate via event listeners and callback functions.
Regardless of components involved, all APIs have three things in common:
| Parts of an API | Server-client | Client-client |
| --- | --- | --- |
| Name and functionality | HTTP path | JavaScript function |
| Parameters | HTTP GET query and POST parameters | Function parameters |
| Return Value | HTTP response, typically JSON format | Function return value |
| Name and functionality | HTTP path | JavaScript function / Event name |
| Parameters | HTTP GET query and POST parameters | Function / event parameters |
| Return Value | HTTP response, typically JSON format | Return values (optional) |
### Server-client API example
### Server-client communication
Using the [News Feed system design](/questions/system-design/news-feed-facebook) example yet again, we have a server API that allows the client to fetch the latest feed posts.
At a high level, all server–client communication boils down to requests and responses, but the specifics depend on the protocol and the application architecture. Here are the major server-client communication mechanisms:
| Field | Value |
| ----------- | ------------------------------------ |
| HTTP Method | `GET` |
| Path | `/feed` |
| Description | Fetches the feed results for a user. |
- **HTTP**: HTTP is the foundation of the web. The client sends a request to a specific URL, and the server responds with data or a document. Each exchange is stateless, meaning the server does not remember previous requests and clients authenticate/identify themselves using session cookies. Most modern HTTP APIs are structured using [RESTful conventions](https://en.wikipedia.org/wiki/REST). HTTP/REST is the most common server-client communication mechanism you will encounter in system design interviews.
- **WebSockets**: WebSockets create a persistent, bidirectional channel between client and server after an initial HTTP handshake. Once open, both sides can send messages at any time without reopening new connections. This makes them ideal for real-time apps such as chats, games, live dashboards, or collaborative editing tools.
- **Server-Sent Events**: SSE allows the server to push a continuous stream of updates to the client over a single long-lived HTTP connection. The client can't send messages back on the same channel, making it one-way (server → client). It's simpler than WebSockets and well-suited for live notifications, stock tickers, or streaming logs.
- **Long polling**: Long polling is not a protocol, it's more of a technique to simulate real-time updates over standard HTTP. The client sends a request and the server holds it open until new data is available, then returns a response. The client immediately reopens another request. Although inefficient compared to WebSockets, it works when persistent connections aren't available. With better alternatives like WebSockets and SSE, long polling is rarely used these days.
- **GraphQL**: GraphQL uses HTTP to let clients request exactly the data they need with a single query. The server interprets the query and returns structured JSON matching the client’s shape. It reduces over-fetching and under-fetching problems common with REST APIs. In interviews, it is unlikely that you will encounter any systems that can only be solved with GraphQL.
- **WebRTC**: WebRTC is a peer-to-peer communication protocol designed for low-latency media and data transfer (e.g., video calls, file sharing). It typically uses a signaling server for connection setup, thereafter data is transmitted directly between clients, without going through the server. WebRTC is used to solve very specific problems
#### Parameters
Most of the time, front end system design interviews will only require knowledge of HTTP, WebSockets and SSE mechanisms.
**Example using News Feed**
Using the [News Feed system design](/questions/system-design/news-feed-facebook) example, the server provides a RESTful HTTP API that allows clients to fetch the latest feed posts.
| Field | Value |
| ----------- | ---------------------------------- |
| HTTP Method | `GET` |
| Path | `/feed` |
| Description | Fetches the feed posts for a user. |
**Parameters**
A feed response is a paginated list so the API expects pagination parameters.
@ -189,7 +257,7 @@ A feed response is a paginated list so the API expects pagination parameters.
}
```
#### Response
**Response**
```json
{
@ -217,13 +285,27 @@ A feed response is a paginated list so the API expects pagination parameters.
}
```
### Client-client API example
### Inter-client communication
The client-client API can be written in a similar fashion as the server-client API, main difference being they are JavaScript functions, or events that are being listened to. The most important parts to describe are the functionality of the API, the parameters and the return/response value.
Communication between modules in a web client, especially those built with modern frameworks, primarily involves mechanisms for **state management**, **event broadcasting**, and direct interaction:
### API for UI component system design
- **Props and callbacks**: This is the foundational component communication. Data moves down from parent to child via props. To communicate back up, the parent passes a callback function down, which the child executes. This establishes a clear, but often deeply nested, communication path.
- **Store dispatching actions**: This involves a centralized data store (e.g., Redux, Zustand, Pinia) that holds the entire application state. Modules don't talk directly; they dispatch actions to the store and subscribe to state changes. This ensures a predictable, unidirectional data flow and simplifies debugging in large applications. Actions are simple objects that contain the action name and action payload.
- **Publish/subscribe via event listeners**: Modules using a publisher/subscriber model communicate without direct knowledge of each other. Modules can subscribe to events with a callback that will be triggered when the event is published. This is highly flexible for non-hierarchical, decoupled communication but can be difficult to trace in complex applications. This is the most prevalent mode of communication in the browser as `window` / DOM elements can listen for events via `element.addEventListener('...')`.
If you're asked to design a UI component, for the "Interface" section, discuss the customization options for the component, similar to the props of a React component.
In system design interviews, modern web apps use some sort of central store that responds to actions. Hence the most common type of inter-client communication present is the store actions and their payload, and how the actions change the store data (data model). Actions can be simple objects that encapsulate the action name and payload (e.g. Flux, Redux), or setters functions on the store object (e.g. Zustand, Pinia).
### UI components API design
In the context of designing UI components, the "Interface" refers to component props. Discuss the props for the each component (parent and children), which tend to fall under one of these categories:
- **Data props**: These provide the data that the component needs to render, e.g. `name`, `title`
- **Event or callback props**: Functions passed down so the child can notify the parent of an event or request an action, e.g. `onClick`, `onSubmit`
- **Configuration or behavior props**: Customize how the component behaves without changing its data, e.g. `isOpen`, `isDisabled`, `timeout`, `maxResults`
- **Styling and presentation props**: These influence visual output or layout, e.g. `className`, `style`, `color`, `size`
- **Render function or slot props**: These invert control and let the parent decide how to render certain parts, e.g. `render`
In interviews, unless you are asked to design a component (e.g. [Autocomplete](/questions/system-design/autocomplete), [Modal dialog](/questions/system-design/modal-dialog), [Dropdown Menu](/questions/system-design/dropdown-menu)) or a component makes up the main part of the product (e.g. [Pinterest's masonry grid](/questions/system-design/pinterest), a fairly complex component), you shouldn't need to spend time on component API design.
---
@ -233,33 +315,74 @@ If you're asked to design a UI component, for the "Interface" section, discuss t
**Recommended duration**: Roughly 40% of the session.
There's no fixed way to go about the optimization and deep dive section and you are free to focus on different areas of the product. There will not be sufficient time to cover every area, so select how you want to spend your time carefully according to these guidelines:
There's no fixed way to go about the optimization and deep dive section and you usually have the flexibility to focus on various areas of the product.
- **Focus on the important areas of the product**: For e-commerce websites, performance is crucial and you'd want to spend the bulk of your time diving into the various performance optimizations that can be done. For collaborative editors, the complexity is in how to handle race conditions and concurrent modifications, so you'd want to focus on explaining that.
- **Focus on your strengths**: Showcase your domain knowledge. If you are well-versed in accessibility, talk about the various accessibility pitfalls that can occur in the product and how to address them. Impress the interviewer with your knowledge. If you are a performance guru, explain the various performance optimization opportunities that can provide a buttery smooth user experience.
However, there will not be sufficient time to cover every area, it's important to decide how you want to spend your time carefully according to these guidelines:
### General optimization / Deep dive areas
**1. Focus on the unique/important areas of the product**. For e-commerce websites, SEO and performance are crucial and you'd want to spend the bulk of your time diving into the various SEO techniques and possible performance optimizations. For collaborative editors, the complexity is in how to handle concurrent modifications and resolving any conflicts, so you'd want to focus on explaining that. Avoid topics that do not affect the architecture, like logging, CSS framework, tooling choices, etc.
Here's a list of topics you can talk about for this section. Bear in mind that the importance of a topic depends on the product and some topics are entirely irrelevant to certain products (possible but unlikely).
**2. Showcase your strengths and knowledge**. If you are well-versed in accessibility, talk about the various accessibility pitfalls that can occur in the product and how to address them. If you are a performance guru, explain the various performance optimization opportunities that can provide a buttery smooth user experience. Impress the interviewer with your knowledge and aim to teach them something new. However, remember to stay relevant to the product, and not start a discussion about something like V8 internals.
- Performance
- User Experience
- Network
### General optimization / deep dive areas
Here's a list of topics you can dive into. Bear in mind that the importance of a topic depends on the product and some topics are entirely irrelevant to certain products.
- Performance optimizations
- Networking techniques and optimization
- User experience
- Accessibility (a11y)
- Multilingual Support
- Multi-device Support
- Search engine optimization
- Multilingual support
- Multi-device support
- Security
Refer to our [Best Practices for Building User Interfaces Guide](/front-end-interview-guidebook/user-interface-questions-cheatsheet) for details on each topic.
### Choosing topics
We emphasize again the importance of staying relevant to the problem/system at hand.
As a general rule of thumb, avoid spending time on the following topics that are not likely to affect the system architecture.
- **JavaScript framework**: Avoid debating React vs Vue vs Angular. The interviewer cares about more how you'd structure the app. Most modern JavaScript frameworks have similar features and most of the time you can build applications using any modern JavaScript framework.
- **Design system / CSS framework**: Leave out framework choices such as Tailwind vs Material UI unless the question explicitly involves UI scalability or theming.
- **General performance optimization**: Don't overemphasize generic advice like minification, image compression, or caching unless it's core to the problem being solved (e.g., rendering at scale, large data visualizations).
- **Auxiliary product infrastructure**: Skip common topics that do not affect the core architecture, like logging, analytics, or monitoring integrations unless they directly influence user experience or system constraints.
- **Irrelevant DevOps or CI/CD details**: Avoid going deep into deployment pipelines, Docker setups, or GitHub Actions unless it directly impacts client performance or front end release management.
- **Tooling**: Don't focus on build tools or developer experience topics like webpack vs Vite, linting configurations, or code formatting.
Remember, if the topic isn't uniquely relevant or important to the system, you likely don't want to spend too much time on it, or at all.
### Exceptions
You should only bring up any of the above topics when they directly affects the architecture or constraints of the system you're designing. In other words, mention it when the choice has meaningful implications, not just as a personal preference.
For e.g., mentioning the JavaScript framework or metaframework is relevant when:
1. The problem domain dictates it. If the system's nature aligns with a particular framework paradigm:
- Example: You're designing a highly dynamic dashboard with complex client-side interactions → React or Vue may be relevant.
- Example: You're building a content-heavy marketing site optimized for SEO → Next.js, Remix, or Nuxt might be worth mentioning due to the ability to perform server-side rendering (SSR) and static site generation (SSG).
2. When performance, rendering, or deployment strategy depends on it. If the architecture discussion involves rendering strategy or performance:
- CSR vs SSR vs SSG vs ISR (e.g., Next.js or Remix enabling SSR and caching at the edge).
- Trade-offs between SPA navigation and server-rendered first loads.
- CDN or edge delivery considerations tied to the framework (e.g., Vercel's Next.js ecosystem).
When not to bring it up:
- When the discussion is about data flow, caching, APIs, or component communication. Those are conceptual and independent of framework choice.
- When you're asked to "design" a system, not "implement" it. Focus on user flow, data handling, state management, and communication patterns first.
Spend time on a topic only when it changes architectural trade-offs — not when it's just an implementation detail or something every application needs.
---
## Summary
| Step | Objective | Recommended duration |
| --- | --- | --- |
| Requirements exploration | Understand the problem thoroughly and determine the scope by asking a number of clarifying questions. | <15% |
| Requirements exploration | Understand the problem thoroughly and determine the scope by asking a number of clarifying questions. | ~10% |
| Architecture / High-level design | Identify the key components of the product and how they are related to each other. | ~20% |
| Data model | Describe the various data entities, the fields they contain and which component(s) they belong to. | ~10% |
| Interface definition (API) | Define the interface (API) between components in the product, functionality of each APIs, their parameters and responses. | ~15% |
| Data model | Describe the various data entities, the fields they contain, and which component(s) they belong to. | ~10% |
| Interface definition (API) | Define the interface (API) between components in the product, functionality of each APIs, their parameters and responses. | ~20% |
| Optimizations and deep dive | Discuss about possible optimization opportunities and specific areas of interest when building the product. | ~40% |

56
packages/system-design/contents/introduction/en-US.mdx
View File

@ -6,45 +6,63 @@ social_title: Front End System Design Playbook | GreatFrontEnd
seo_description: The definitive guide to front end system design interviews. Learn useful techniques and how to approach the most common questions. Written by Ex-FAANG interviewers.
---
Unlike coding and quiz questions, system design interviews are open-ended style interviews where there are no right answers. You're given a vague problem or scenario and you're expected to work with the interviewer to answer the question by coming up with a suitable software design on a whiteboard, or some collaborative drawing app if it's a virtual interview. It is similar to the process at certain companies where engineers write technical design documents to outline the possible approaches to a project they are working on, explain technical decisions and discuss tradeoffs with coworkers except that you have to do it within 30-60 minutes.
Unlike coding and quiz questions, system design interviews are open-ended style interviews where there are no right answers. Candidates are given a vague problem or scenario and they are expected to work with the interviewer to answer the question by coming up with a suitable software design on a whiteboard, or in the case of virtual interviews, a collaborative drawing app like Excalidraw.
System design interviews are usually given to candidates who have some number of years of working experience (aka non-fresh grads) and your performance in the system design interview has significant influence on the job level you will be offered. Most of the time, failing the system design interview will result in an overall rejection. It's really important to ace your system design interviews!
In many ways, system design interviews are similar to the process at certain companies where engineers write technical design documents to outline the possible approaches to a project they are working on, explain technical decisions, and discuss tradeoffs with coworkers except that time is limited (around 30-60 minutes).
However, given the open-ended nature of system design interviews, it is much harder to practice for it as compared to coding interviews. Many candidates also don't have real life experience building various systems and it's hard to draw from experience when answering system design interview questions. Also, there are very few resources available for front end system design. Most existing system design resources are targeted at general Software Engineers and hence focus on distributed systems.
System design interviews are usually asked to candidates who have some number of years of working experience (aka non-fresh grads) and their performance in the system design interview has significant influence on the job level and salary offered. Most of the time, failing the system design interview will result in an overall rejection. If you are targeting senior and beyond levels, it's really important to ace your system design interviews!
GreatFrontEnd's front end system design resources are perhaps the most comprehensive you can find and will help you ace your front end system design interviews with ease!
Given the open-ended nature of system design interviews, it is much harder to practice for it as compared to coding interviews. Many candidates also don't have real life experience building various systems and it's hard to draw from experience when answering system design interview questions. Also, there are very few resources available for front end system design. Most existing system design resources are targeted at general Software Engineers and hence focus on distributed systems.
{/* TODO: Add some testimonials regarding front end system design */}
GreatFrontEnd aims to fill the gap with this Front End System Design Playbook. This guide is among the most comprehensive front end system design resource available and will help you ace your front end system design interviews even if you do not have much experience.
## Front end vs Back end / Full stack system design
In traditional Software Engineer system design interviews, candidates will be asked to describe the architecture of a distributed system, usually involving web servers, API gateways, load balancers, caches, databases, microservices, message queues, streams, etc.
In traditional Software Engineer system design interviews, candidates are asked to describe the architecture of a distributed system, usually involving cloud infrastructure — web servers, API gateways, load balancers, caches, databases, microservices, message queues, streams, etc.
For Front End Engineers, system design interviews are slightly different – there's more emphasis on what goes on in the client and API design between the client and the server, as opposed to what goes on in the back end.
Front end system design interviews are slightly different – there's more emphasis on what goes on in the client and the API details between clients and servers, as opposed to what goes on in the back end.
| Area | Back end / Full stack | Front end |
| Aspect | Back end / Full stack | Front end |
| --- | --- | --- |
| Gather requirements | Required | Required |
| Architecture / High-level design entities | Distributed cloud services | Application/Component |
| Back-of-the-envelope estimation | May be required | Not required |
| Components of the system | Cloud services (e.g. Load balancer, Application server, Database, File storage, Caches, Message queues, CDN, Full-text search) | Application modules (Model, View, Controller) |
| Architecture / High-level entities | Distributed cloud services (e.g. Load balancer, Application server, Database, File storage, Caches, Message queues, CDN, Full-text search) | Components within the client (View, Store, Networking layer) |
| Back-of-the-envelope capacity estimation | May be required | Usually not required |
| Data model | Database schema | Application state |
| Type of APIs between components | Network (Any protocol) | Network (HTTP, WebSocket), JavaScript functions |
| Deep dives / focus areas | Scalability, Reliability, Consistency, Availability | Performance, User Experience, Accessibility, Internationalization |
| Less important (Can treat as a black box) | Client | Server |
| Type of APIs between components | Between distributed services (HTTP, gRPC, etc.) | Between server and client (HTTP, WebSocket), Events / actions between client-side components |
| Deep dives / focus areas | Scalability, Reliability, Consistency, Availability | Performance, User Experience, Accessibility, Internationalization |
For example, a classic question is to ask about designing a Facebook news feed which can be asked during both back end and front end system interviews.
For example, a classic question is to "Design the Facebook news feed". This question can be asked in both back end and front end system interviews, but the focus is entirely different:
- **Back end / Full stack**: Capacity estimation, designing the database schema, APIs between microservices, how to ensure the services can scale with the traffic, how to generate a user's news feed in a scalable fashion, what happens when a post is created by a typical user (hundreds of followers) vs celebrities (millions of followers)
- **Front end**: HTTP API for the feed, how to implement feed pagination, how to implement interactions with posts, how new posts can be created, user experience and accessibility considerations
- **Back end / full stack system design**: Capacity estimation, designing the database schema, APIs between microservices, scaling services for high traffic, how to generate a user's news feed in a scalable fashion, what happens when a post is created by a typical user (hundreds of followers) vs celebrities (millions of followers)
- **Front end system design**: HTTP API to fetch the feed, implementing feed pagination, implementing interactions with posts (liking, commenting), how users can create new posts, performance, user experience, and accessibility considerations
As you can see, the focus of front end system design interviews can be very different from back end, and answering them well requires a different approach.
To excel in front end system design interviews, knowing what topics to focus on is paramount.
## What you will learn in this guide
Our Front End System Design guide is structured into two parts, you will first gain a deeper understanding of what system design interviews are about, then dive into some front end system design case studies that use the RADIO framework.
Our Front End System Design guide is structured into a few parts, you will first gain a deeper understanding of the types of front end system design interviews, then learn a framework to approach front end system design interviews. Lastly, you will learn how candidates are being evaluated and what common mistakes candidates make.
- [Types of questions](/system-design/types-of-questions): Types of Front End System Design interview questions and examples
- [RADIO framework](/system-design/framework): A framework for answering Front End System Design interview questions
- [RADIO framework by GreatFrontEnd](/system-design/framework): A framework for approaching Front End System Design interview questions
- [Evaluation axes](/system-design/evaluation-axes): How you are being evaluated and what interviewers are looking out for
- [Common mistakes](/system-design/common-mistakes): Common mistakes to avoid during Front End System Design interviews
## How to use this guide
We recommend reading the entire Front End System Design playbook cover-to-cover (entirely free) since it's not that long but full of important information. It aims to give you an overview of front end system design interviews and help you understand how to excel in your interviews.
After which, go through the case studies like [News Feed](/questions/system-design/news-feed-facebook) and [Autocomplete](/questions/system-design/autocomplete). These case studies give you a sense of how to approach the two kinds of questions you can encounter in front end system design interviews. Along the way, you will pick up techniques that can be broadly applied to other questions.
Beyond these two case studies, we also dive into niche front end systems such as:
- Search engine optimization: Airbnb
- E-commerce performance optimization: Amazon
- Media upload and optimization: Instagram
- Media streaming: Netflix
- Rich text editing: Lexical rich text editor
- Real-time collaboration and conflict resolution: Google docs
- Real-time messaging: Messenger
- Design system components: Dropdown menu, Image carousel, Modal dialog
You can sign up for the [Premium membership](/interviews/pricing), which gives you full access to all case studies.

68
packages/system-design/contents/types-of-questions/en-US.mdx
View File

@ -10,50 +10,52 @@ There are two main kinds of front end system design questions: (1) Applications
## Applications
As mentioned above, designing applications for front end system design interviews will feel similar to general Software Engineering system design interviews, and in fact, the questions are highly similar. However, instead of talking about distributed systems, you should focus on the client side of things and talk about application architecture and client-side implementation details.
Designing applications for front end system design interviews will feel similar to general Software Engineering system design interviews, and in fact, the questions are highly similar. However, instead of talking about distributed systems, focus on how things work within the client — discuss the application architecture and how it can communicate with the server.
In this day and age, many websites are interactive and rich applications that can do virtually what many desktop applications can. If you've used Gmail, Facebook, YouTube, ChatGPT, or Google Calender on the web, you have used a web app. Web apps tend to be interactive and dynamic (contents on the page change frequently) and page navigations in a web app usually don't require a full page refresh; the app uses JavaScript to fetch remote data for the next page and dynamically change the contents and URL.
In this day and age, many websites are interactive and rich applications that can do virtually what many desktop applications can. If you've used Gmail, Facebook, YouTube, ChatGPT, or Google Calender on the web, you have used a web app. Web apps tend to be interactive and dynamic (contents on the page change frequently) and page navigation in a web app usually don't require a full page refresh; web apps use JavaScript to fetch remote data for the next page and dynamically change the contents and URL.
Since web apps are complex software involving multiple modules, common application architectures learnt in Software Engineering classes like Model-View-Controller (MVC), Model-View-ViewModel (MVVM) are also applicable when building web apps. React is one of the most popular JavaScript libraries by Facebook to build interactive web applications and many React web apps adopt a unidirectional Flux/Redux-based architecture.
Since web apps are complex software involving multiple modules, common application architectures learnt in Software Engineering classes like Model-View-Controller (MVC), Model-View-ViewModel (MVVM) are also applicable when building web apps. React is one of the most popular JavaScript libraries by Facebook to build interactive web applications and many React web apps adopt a unidirectional reducer architecture (e.g. Flux/Redux).
Different applications have their own unique aspects and talking points. It's imperative that you focus on the parts that are unique to the application and not spend too much time talking about general stuff that are applicable to all questions. Firstly, design the high-level architecture, identify the components in the system, and the API between the components. Then dive into a few areas that are interesting/unique to the problem and how to implement or optimize them.
Each web app has its own unique challenges and certain topics matter more than others. For example, for an e-commerce marketplace, search engine optimization (SEO) and performance are extremely important because they have a direct impact on sales. On the other hand, a messaging app isn't meant to be indexable by search engines and it's therefore not meaningful to discuss about SEO. Instead, candidates should spend more time on real-time communication protocols, which directly affects the core value proposition of the app.
### Examples
### Important areas
Here's a list of application questions commonly asked during front end system design interviews and the areas you should focus on:
Here's a list of commonly-asked applications during front end system design interviews and the important features and areas to focus on:
| Application | Examples | Important areas |
| --- | --- | --- |
| [News Feed](/questions/system-design/news-feed-facebook) | Facebook, Twitter | Feed interactions, Feed pagination approaches, Post composer |
| [Messaging/Chat](/questions/system-design/chat-application-messenger) | Messenger, Slack, Discord | Real-time chat, Message syncing, Messages list, Chat list |
| [E-commerce Marketplaces](/questions/system-design/e-commerce-amazon) | Amazon, eBay | Product listing pages, Product detail pages, Cart, Checkout |
| [Photo Sharing](/questions/system-design/photo-sharing-instagram) | Instagram, Flickr, Google Photos | Photos browsing, Photos editing, Photos uploading |
| [Travel Booking](/questions/system-design/travel-booking-airbnb) | Airbnb, Skyscanner | Search UI, Search results, Booking UI |
| [Video Streaming](/questions/system-design/video-streaming-netflix) | Netflix, YouTube | Video player, Video streaming, Recommended videos |
| [Pinterest](/questions/system-design/pinterest) | Pinterest | Masonry layout implementation and media feed optimizations |
| [Collaborative Apps](/questions/system-design/collaborative-editor-google-docs) | Google Docs, Google Sheets, Google Slides, Notion | Real-time collaboration protocols, Conflict resolution, State syncing |
| [Email Client](/questions/system-design/email-client-outlook) | Outlook, Apple Mail, Gmail | Mailbox syncing, Mailbox UI, Email composer |
| Drawing | Figma, Excalidraw, Canva | Rendering approach, Client state/data model, State management |
| Maps | Google/Apple Maps, Foursquare City Guide | Map rendering, Displaying locations |
| File Storage | Google Drive, Dropbox | File uploading, File downloading, File explorer |
| Video Conferencing | Zoom, Google Meet | Video streaming, Various viewing modes |
| Ridesharing | Uber, Lyft | Trip booking, Driver location, App states |
| Music Streaming | Spotify, Apple Music | Audio streaming, Music player UI, Playlists UI |
| Games | Tetris, Snake | Game state, Game loop, Game logic |
| Application | Examples | Important features | Important topics |
| --- | --- | --- | --- |
| [News feed](/questions/system-design/news-feed-facebook) | Facebook, Twitter | Feed list, Feed interactions, Post composer | Pagination approaches, Performance |
| [Messaging/Chat](/questions/system-design/chat-application-messenger) | Messenger, Slack, Discord | Real-time messaging | Real-time communication protocols |
| [E-commerce marketplaces](/questions/system-design/e-commerce-amazon) | Amazon, eBay | Product listing pages, Product detail pages, Cart & Checkout | SEO, performance |
| [Photo sharing](/questions/system-design/photo-sharing-instagram) | Instagram, Flickr, Google Photos | Photos browsing, Photos editing, Photos uploading | Media optimization |
| [Travel booking](/questions/system-design/travel-booking-airbnb) | Airbnb, Skyscanner | Search UI, Search results, Booking UI | SEO, Performance |
| [Video streaming](/questions/system-design/video-streaming-netflix) | Netflix, YouTube | Video player, Video streaming | Streaming implementation |
| [Pinterest](/questions/system-design/pinterest) | Pinterest | Masonry layout implementation | Media optimizations |
| [Collaborative apps](/questions/system-design/collaborative-editor-google-docs) | Google Docs, Google Sheets, Google Slides, Notion | Real-time collaboration | Real-time collaboration protocols, Conflict resolution, State syncing |
| [Email client](/questions/system-design/email-client-outlook) | Outlook, Apple Mail, Gmail | Mailbox syncing, Mailbox UI, Email composer | App state, offline usage |
| Drawing | Figma, Excalidraw, Canva | Canvas, Client state/data model, State management | Canvas rendering implementation |
| Maps | Google/Apple Maps, Foursquare City Guide | Map rendering, Displaying locations | Map rendering and interactions |
| File storage | Google Drive, Dropbox | File uploading, File downloading, File explorer | Uploading experience |
| Video conferencing | Zoom, Google Meet | Video streaming, Various viewing modes | Video streaming, Performance |
| Ridesharing | Uber, Lyft | Trip booking, Driver location | App state |
| Music streaming | Spotify, Apple Music | Audio streaming, Music player UI, Playlists UI | Media streaming, app state |
| Games | Tetris, Snake | Game state, Game loop, Game logic | Same as features |
## UI components
In modern front end development, it is common to use component libraries to build applications. Some popular component libraries you might have used before include jQuery UI (how old school!), Bootstrap, Material UI, Chakra UI, etc.
In modern front end development, it is common to use component libraries to build applications. Some popular component libraries you might have used before include Radix UI,jQuery UI, Bootstrap, Material UI, Chakra UI, etc.
It is an expectation of Front End Engineers to be able to build the various UI components needed by an application. Some UI components can be easy to build (e.g. text, button, badge, etc), while others can be much more complex (autocomplete, dropdown, modal, etc). Most of the time, if you are asked to design a UI component, it would be from the latter category.
It is an expectation of Front End Engineers to be able to build the various UI components needed by an application. Some UI components can be easy to build (e.g. text, button, badge, etc), while others can be much more complex (autocomplete, dropdown, modal, etc) because it involves more interactions, components, and stricter accessibility requirements. Most of the time, if you are asked to design a UI component, it would be from the latter category.
Firstly determine the subcomponents of the component (e.g. for an image carousel, there's the image, the pagination buttons, thumbnails), define the external-facing API of the component (what options/props the component should accept), describe the internal component state, API between the subcomponents (if relevant), then dive into optimizations and considerations for performance, accessibility, user experience, security, etc where relevant.
To approach system design for UI components, determine the subcomponents of the components, define the external-facing API of the component (what options/props the component should accept), describe the internal component state, API between the subcomponents (if relevant), then dive into optimizations and considerations for performance, accessibility, user experience, security, etc., where relevant.
You might have to write a small amount of code for one or more of the following purposes:
1. Describe the component hierarchy
1. Describe the shape of the component state
1. Explain some non-trivial logic within the component
2. Describe the shape of the component state
3. Explain some non-trivial logic within the component
For example, an image carousel would contain the current image, pagination buttons, and preview thumbnails.
```jsx
<ImageCarousel
@ -76,14 +78,16 @@ Examples of UI components asked during front end system design interviews:
- Design an [autocomplete component](/questions/system-design/autocomplete)
- Design a [dropdown menu component](/questions/system-design/dropdown-menu)
- Design an [embeddable poll widget](/questions/system-design/poll-widget)
- Design an [image carousel](/questions/system-design/image-carousel)
- Design a [modal component](/questions/system-design/modal-dialog)
- Design an [embeddable poll widget](/questions/system-design/poll-widget)
- Design a [rich text editor](/questions/system-design/rich-text-editor)
- Design a [modal component](/questions/system-design/modal-dialog)
- Design a data table with sorting and pagination
- Design a datepicker
- Design a multiselect component
## What to do during interviews?
Now that you have an understanding of the kind of questions you can be asked during Front end system design interviews, how do you go about answering them? We came up with the [RADIO framework](/system-design/framework), an easy-to-remember structured approach that you can use to ace Front End system design interview questions.
Now that you have an understanding of the kind of questions you can be asked during Front end system design interviews, how do you go about answering them?
At GreatFrontEnd, we invented the [RADIO framework](/system-design/framework), an easy-to-remember and structured approach that you can use to ace Front End system design interview questions.