Frontend System Design Interview: The RADIO Framework with a Worked Autocomplete Example

Senior frontend interviews almost always have a system design round. You won't be designing databases and load balancers. You design a product from the browser's side: "Design an autocomplete", "Design a news feed", "Design a chat app", "Design an image carousel". There is no single right answer. The interviewer wants to see three things: can you give shape to an open problem, can you make sensible trade-offs, and can you go deep on the parts that affect the user.

This post gives you a framework you can repeat, one full worked example (autocomplete), and checklists you can reuse for other questions.

1. How it differs from backend system design

Backend rounds are about storage, scaling, replication and throughput. Frontend rounds treat the server mostly as a black box with an API. They focus on:

• Component architecture: how the UI is split and how data flows between parts.
• Client state and caching: what data lives where, what is calculated from other data, and when it goes stale.
• API design from the client's side: what the UI needs, pagination, payload size.
• User experience in real life: slow networks, long lists, errors, keyboard and screen-reader users, different screen sizes.
• Performance: rendering cost, bundle size, perceived speed.

2. The RADIO framework

An easy way to plan a 45 to 60 minute round is RADIO: Requirements, Architecture, Data model, Interface, Optimisations. Say this plan out loud at the start. It shows the interviewer you are organised.

• Requirements: ask questions before you draw anything. What are the core features? Which devices? How much data? Does it need to work offline? Are accessibility or multiple languages in scope? Write down the functional and non-functional requirements.
• Architecture: draw the main pieces (view components, a controller or store, a client cache, the server API) and the arrows between them. Say which parts are rendered on the server and which are interactive.
• Data model: describe the client state. Which data comes from the server, which is only UI state, what is normalised, what is computed from other data.
• Interface: define the API between client and server (endpoints, parameters, response shape, pagination), and the props or events of the main components.
• Optimisations: go deep on performance, network, UX edge cases, accessibility and security. Pick the two or three areas that matter most for this particular product.

3. Worked example: design an autocomplete

Requirements

• Functional: as the user types, show up to 10 suggestions. Picking one (by click or keyboard) fills the input and starts a search. Results can be plain text or richer items with images.
• Non-functional: feels instant, works on mobile and slow networks, fully usable with a keyboard and a screen reader, and reusable on different pages of the product.
• Ask: is the data small enough to send to the client (like a country list), or does it need a server (like product search)? Here we assume server search.

Architecture

• Input: a text field that emits the current query.
• Results list: renders suggestions, highlights the active item, handles clicks.
• Controller: owns the state, decides when to call the API, talks to the cache, and handles keyboard navigation.
• Cache: maps query strings to results so repeated queries are instant.
• Server API: returns suggestions for a query.

Make it a reusable component that others can customise: a function to fetch results, a function to render each item, and callbacks for selection.

Data model

state = {
  query: "reac",
  results: Suggestion[],        // for the current query
  status: "idle" | "loading" | "success" | "error",
  activeIndex: -1,              // keyboard-highlighted item
  isOpen: boolean
}
cache = Map<string, { results: Suggestion[], fetchedAt: number }>

Interface

GET /api/suggest?q=reac&limit=10
-> { query: "reac", results: [{ id, label, type, imageUrl? }] }

<Autocomplete
  fetchSuggestions={(q, signal) => Promise<Suggestion[]>}
  renderItem={(item, { active }) => ReactNode}
  onSelect={(item) => void}
  minChars={2}
  debounceMs={250}
/>

Optimisations

• Debounce the input by about 200 to 300 ms, so you don't send a request on every keystroke. Skip queries shorter than a minimum length.
• Handle race conditions. Responses can come back out of order. The answer for "re" may arrive after the one for "react". Cancel the previous request with AbortController, or ignore any response whose query no longer matches the input.
• Cache results for each query, with a time-to-live and a size limit (for example, least recently used). Now backspacing is instant. While a request is still in flight, you can also filter the cached results of a shorter prefix locally.
• Accessibility: use the ARIA combobox pattern. Put role="combobox" on the input with aria-expanded, and aria-controls pointing to a role="listbox". Give items role="option", and use aria-activedescendant for the highlighted item. Support Up, Down, Enter and Escape.
• Perceived performance: show a small loading state only if a request takes more than about 150 ms, so the UI doesn't flicker. Highlight the part of each suggestion that matches.
• Large result sets: virtualise the list if it can be long. Lazy-load images in suggestions.
• Error and empty states: show "No results", offer a retry when a request fails, and never block typing.
• Mobile: use large tap targets, don't let the on-screen keyboard hide the results, and use inputmode and enterkeyhint.
• Security: render labels as text, not HTML, so highlighting matches can't open an XSS hole.

4. Quick outline: design a news feed

• Requirements: an endless scroll of posts with text, images and video. Users can like and comment, new posts show up, and it works on slow mobile networks.
• Architecture: render the first page on the server for a fast first paint. Use client components for interactions, and a normalised store for posts and users.
• Data model: posts by id, users by id, a feed array of post ids, and a pagination cursor.
• Interface: GET /feed?cursor=abc&limit=20 with cursor-based pagination. Offsets break when new posts get added at the top.
• Optimisations: use IntersectionObserver to load the next page. Virtualise the list for very long sessions. Lazy-load responsive images and reserve their space so the layout doesn't shift. Make likes optimistic and roll back on error. Show a "New posts" pill instead of moving content under the user. Keep the scroll position on back navigation.

5. Optimisation checklist

Area	Things to mention
Network	Debounce and throttle, request cancellation, caching and stale-while-revalidate, pagination, compression, prefetching likely next steps
Rendering	Virtualisation, memoisation, splitting state so updates stay local, avoiding layout thrashing, transitions for non-urgent updates
Loading	Code splitting, lazy-loading below-the-fold content, image formats and sizes, server rendering for first paint, streaming
UX	Loading, empty and error states, optimistic updates, offline support, preserving scroll and input state
Accessibility	Semantic HTML, keyboard support, focus management, ARIA patterns, colour contrast, reduced motion
Internationalisation	Text expansion, right-to-left layouts, date and number formatting
Security	XSS (never inject untrusted HTML), CSRF on mutations, not storing tokens in localStorage where avoidable
Observability	Core Web Vitals from real users, error tracking, logging failed requests

6. Mistakes that cost candidates

• Jumping straight into components without asking a single requirements question.
• Spending 20 minutes on the backend database. That is not what a frontend round is testing.
• Throwing buzzwords around ("we'll use memo and lazy loading") without saying where and why.
• Ignoring accessibility and error states. These are what set senior answers apart from junior ones.
• Poor time management. Keep at least a third of the round for optimisations and the interviewer's deeper questions.