Topic 25.1
How to Approach Frontend System Design
In one line
Frontend system design is planning a product's client side before building it; the RADIO steps (Requirements, Architecture, Data model, Interface, Optimisations) give you an order to follow, a time plan for a 45–60 minute interview and a shape for a real design doc.
Think of it like this
Building a treehouse. You don't start by hammering. First you ask who it's for and how many kids will climb it (requirements). Then you sketch the platform, the ladder and the roof (architecture). You list the planks and ropes you need (data model). You decide where the ladder meets the ground and the door opens (interface). Last, you make it safer and nicer: rails, a rope that doesn't fray (optimisations). A frontend design follows the same order.
Words you'll meet
New words in this topic, in plain English. Come back here whenever one feels fuzzy.
- Frontend system design
- Planning the client side of a product (screens, components, data, API use, speed, accessibility) before building it.
- RADIO
- A five-step order for a design: Requirements, Architecture, Data model, Interface, Optimisations.
- Functional requirement
- Something the product does: "users can like a post".
- Non-functional requirement
- How well it does it: speed, accessibility, languages, offline, security. Best written with numbers.
- Performance budget
- A hard limit the team agrees to stay under, like "LCP under 2.5 s" or "under 170 KB of JavaScript".
- Latency budget
- The longest an action may take before it feels slow, like "suggestions within 100 ms of typing".
- Clarifying question
- A question you ask before designing, whose answer changes the design.
- Design doc
- A written plan for a feature that teammates review before it's built. RADIO steps make good headings.
Step by step
01Step 0: Restate the problem and ask questions
Say the problem back in one sentence: "We're designing the web client of a social news feed." Then ask the questions that change the design: devices, SEO, freshness, offline, scale, what's out of scope. Write the answers in a list you keep on screen.
If the interviewer says "you decide", decide out loud: "I'll assume mobile web matters most, so I'll budget for a mid-range phone." A stated assumption is worth as much as an answer.
02Step 1: Requirements with numbers
Split functional from non-functional. Then put numbers on the non-functional side, because numbers drive decisions: 20 posts per page means about 40 KB of JSON per request; a user who scrolls past 500 posts would put 20,000 DOM nodes on the page without virtualisation.
Functional
- Scroll an endless feed of posts (text + up to 4 images)
- Like a post, see the count change at once
- See "New posts" when fresh ones arrive
Non-functional
- First posts visible: LCP < 2.5 s on a mid-range phone, 4G
- Interaction: INP < 200 ms, scrolling at 60 fps
- 20 posts per page, heavy users scroll 500+ posts
- Keyboard and screen-reader usable (WCAG 2.2 AA)
- Out of scope: posting video, moderation tools03Step 2: Architecture as a picture
Draw the main parts and the arrows between them: the server (a box), the API layer, the client cache or store, the top-level components and the server/client boundary if you use server rendering. Name each part's single job. Then draw the component tree for the main screen.
04Step 3: Data model and Interface
Write the client-side types (what an entity looks like, how entities reference each other) and the API: endpoints or socket messages with their request and response shapes, including pagination. Keep the two sides consistent: if the response has nextCursor, the store has somewhere to keep it.
type Post = { id: string; authorId: string; text: string; likeCount: number; likedByMe: boolean; createdAt: string };
type FeedPage = { items: Post[]; nextCursor: string | null };
// GET /api/feed?cursor=abc&limit=20 -> FeedPage05Step 4: Optimisations, the deep dives
Pick the 3–4 topics that matter most for *this* product and go deep: rendering choice, caching, virtualisation, optimistic updates, offline, accessibility, internationalisation, security, monitoring. For a feed, the infinite list and optimistic likes matter; for a dashboard, polling and chart performance matter. Depth beats a long list of buzzwords.
06Step 5: Close with trade-offs and next steps
In the last minutes, summarise what you chose and what you'd revisit with more time or more scale. "I chose cursor pagination over offsets because new posts shift offsets. With more time I'd add offline reading with a service worker." This shows you know the design isn't finished, which is how real systems are.
Try it yourself
- 1
Plan your own interview
In the time-plan example, predict the 60-minute split before you switch the select. Then change the shares so Requirements gets 0.15 and Optimisations 0.33. Does the total still add up? Why does rounding the running total guarantee it?
- 2
Find the threshold
In the decisions example, lower
scrolleduntil the decision flips to "a plain list is fine". Predict the number first: with 40 nodes per post and a 3000-node threshold, where does it flip?Set
freshSecondsto 5. Which transport does the rule pick, and would you agree for a stock ticker? For a weekly report? - 3
Write your requirements
Pick an app you use daily (a music player, a food-delivery app). Write five functional and five non-functional requirements, each non-functional one with a number. Then write three clarifying questions whose answers would change your design.
Code & diagrams
The console shows minutes per step (first letter of each step). Optimisations gets the biggest slice because that's where depth is scored. Switch to 60 minutes: every step grows, and the total still adds up because rounding happens on the running total.
Preview
Console
Nothing logged yet.Expected console output
45 min: R 5, A 9, D 5, I 6, O 17, W 3
60 min: R 6, A 12, D 7, I 8, O 23, W 4Requirements with numbers lead straight to decisions. Change `scrolled` to 50 or tick "needs SEO" and watch the decisions change. The thresholds are rules of thumb for this demo, not universal constants.
Preview
Console
Nothing logged yet.Expected console output
JSON per page: about 40 KB
DOM nodes after scrolling: 20000
Decision: virtualise the list
Decision: client rendering is fine
Decision: poll every 30 s# Design: <feature name>
Author, reviewers, status, date
## 1. Requirements
Functional (bullets). Non-functional with numbers (users, items, budgets).
Out of scope. Open questions.
## 2. Architecture
Diagram. Component tree. Rendering choice (CSR/SSR/SSG/streaming) and why.
Where state lives: server cache, client store, URL, local component state.
## 3. Data model
Types for each entity. Normalised store shape. What's derived, not stored.
## 4. Interface
Endpoints / messages: request, response, errors, pagination, real-time events.
Key component props.
## 5. Optimisations
Performance (budgets, virtualisation, code splitting), accessibility, i18n,
security (XSS, auth), offline, monitoring and alerts.
## 6. Alternatives considered and trade-offs
## 7. Rollout: feature flag, metrics to watch, rollback planBreak it on purpose
Errors are the best teachers. Make each change, read the error, guess what went wrong, then reveal the answer.
Break #1
Spend half the interview on requirements
In the time-plan example, change the Requirements share to 0.5 and Optimisations to 0.0 (leave the others). Look at the console.
Myth vs fact
Myth
Frontend system design is the backend design round with React words.
Fact
It treats the server as an API and goes deep on the client: rendering strategy, state placement, caching in the browser, virtualisation, accessibility, offline, bundle size. Databases and sharding are usually out of scope.
Myth
You must follow RADIO rigidly, step by step.
Fact
RADIO is an order, not a script. If the interviewer jumps to the infinite list, follow them. Return to the steps you skipped if there's time.
Myth
Naming many technologies shows seniority.
Fact
Explaining one mechanism properly (how a cursor survives new inserts, how a combobox announces options) and its trade-off scores higher than a list of library names.
Myth
Non-functional requirements are vague by nature.
Fact
Each one can be measured: LCP under 2.5 s, INP under 200 ms, WCAG 2.2 AA, 20 items per page, works offline for reading. Numbers make them testable and drive decisions.
Pro corner
Extra depth for experienced readers. New to this? Skip it for now and come back later.
- ▸
A strong opener is a one-line product summary plus the primary user journey ("a user opens the app, sees posts in under a second, scrolls, likes"). Every later decision can be checked against that journey.
- ▸
Interviewers often hold back a twist ("now it must work offline", "now 100k items"). Designs with clear seams (an API layer, a normalised store, a list component that accepts any renderer) absorb twists with small changes; say so when it happens.
- ▸
In a real team the design doc ends with a rollout plan: a feature flag, the metrics that prove it works (error rate, Core Web Vitals per route, conversion) and how to roll back. Mentioning this in an interview signals production experience (Phase 23).
- ▸
The RADIO name was popularised by frontend interview-prep material; other teams use different words for the same steps. What matters is the order: constraints first, structure next, depth last.
Remember this
- 1
Frontend system design (FSD) means planning the client side of a product: the part that runs in the browser. You decide what it must do, how the screen splits into components, where each piece of data lives, what the browser asks the server for, and how the app stays fast, accessible and secure. A backend system design (see /system-design) is about servers, databases and queues; a frontend design treats the server as a box with an API and focuses on everything from that API to the user's eyes and fingers.
- 2
RADIO is a five-step order for the conversation. Requirements: what the product does and how well it must do it. Architecture: the main parts (components, stores, API layer, server boundary) and how data flows between them. Data model: the shapes of the data in the client, often as TypeScript types. Interface: the API between client and server (endpoints, request and response shapes, real-time messages) and between important components (props). Optimisations: the deep dives, such as performance, accessibility, offline, security and monitoring. The order matters because each step uses the answers of the one before it.
- 3
Functional requirements say *what* the product does: "users can post, like and scroll a feed". Non-functional requirements (NFRs) say *how well*: "the first posts appear within 1 second on a mid-range phone on 4G", "works with a screen reader", "supports 10 languages". NFRs are where frontend design gets interesting, so always turn them into numbers: how many users, how many items per page, how many items a heavy user scrolls past, a latency budget (how long an action may take) and a performance budget (limits such as "under 170 KB of JavaScript, gzipped" or "LCP under 2.5 s").
- 4
Clarifying questions come first and are scored. Good ones change the design: Which devices (desktop, mobile web, both)? Is SEO needed, which decides server rendering? How fresh must data be: real time, seconds, or minutes? Must it work offline? How many items, and how big? Who are the users (internal tool versus global consumer app)? What is out of scope (moderation, admin panel)? Write the answers down where the interviewer can see them, then make assumptions out loud for anything they leave open.
- 5
Time-boxing keeps you from running out of clock with nothing deep said. For a 45-minute round a good split is about 5 minutes requirements, 9 architecture, 5 data model, 6 interface, 17 optimisations and 3 for questions; for 60 minutes scale each part up. Most of the score sits in architecture and optimisations, because that's where seniority shows. If the interviewer steers you ("let's talk about the infinite list"), follow them: their steering tells you what they want to score.
- 6
What interviewers score: (1) problem exploration, meaning you asked questions that matter and wrote down numbers; (2) architecture, meaning clear parts with clear jobs and a sensible server/client split; (3) technical depth, meaning real mechanisms (cursor pagination, normalised caches, virtualisation, ARIA patterns) rather than buzzwords; (4) trade-offs, meaning you name two options and say why you'd pick one *for this product*; (5) user experience, meaning loading, empty and error states, accessibility and mobile; (6) communication, meaning a structured story the interviewer can follow. In a real team the same RADIO structure becomes the headings of a design doc that other engineers review before the build.
Explain it without notes
Walk me through how you'd structure a 45-minute frontend system design interview.
What's the difference between functional and non-functional requirements? Give three non-functional requirements with numbers for a photo-sharing app.
Which clarifying questions would you ask before designing a frontend, and how does each answer change the design?
What do interviewers look for in a frontend system design round?
Practice
Write the requirements (functional, non-functional with numbers, out of scope) for an image carousel on a product page.
Change the time-plan example so it also shows the plan as percentages next to the minutes.
Trade-offs
- ↔
More time on requirements makes the design fit the product better but leaves less time for the depth that is scored. Ask the questions that change the design and assume the rest out loud.
- ↔
Going broad (touching every optimisation) shows awareness; going deep (one optimisation properly) shows skill. Do a quick list, then pick two or three to explain in depth.
Done when you can
I can name the RADIO steps and what each produces.
I can split requirements into functional and non-functional, with numbers.
I can list clarifying questions that change a frontend design.
I can time-box a 45- or 60-minute design round.
I know what interviewers score and can structure a design doc the same way.