Designing a Frontend System from A to Z

In an interview, you typically have 45–60 minutes to design a client-side product (e.g., News Feed, Autocomplete, Chat, Photo Gallery). The interviewer evaluates how systematically you think, not how many APIs you remember.

The RADIO framework — the backbone of every answer.

RADIO is a popular mnemonic to help you not miss any steps. Proceed sequentially but be flexible to revisit steps when needed.

Self-assessment quick check

Classification of requirements

Essential questions to ask.

• **Users & Scale:** Who uses it? How many concurrent users? Primary device types?
• Core features: Which features are mandatory for MVP? Which are "nice-to-have"?
• Data: Does the data change frequently? Is real-time required?
• Performance: Are there specific targets (e.g., LCP < 2.5s)?
• SEO: Does the page need to be indexed by Google? (Significantly impacts rendering pattern)
• Offline: Does it need to work when there is no network connection?
• Cross-platform: Web-only or need to share logic with mobile app?
• i18n / a11y: Do you need to support multiple languages, RTL, and screen readers?

Common client architecture (layered)

Idea: data flows from Server → Network → Store → View Model → View, while events flow in the opposite direction. Each layer can be tested and replaced independently.

Container / Presentational pattern

When to use Micro-frontends?

Micro-frontend splits a large application into multiple independent parts, each owned by a team (potentially using different frameworks). It is effective for **large organizations with many teams**, but increases complexity in build processes, duplicate bundles, and UX consistency.

Visually compare the timeline.

Hydration & modern variants

Hydration is the process of attaching JavaScript event handlers to server-generated HTML, turning a "static" page into an "interactive" one. The issue: it can be heavy and delay Time to Interactive (TTI). Techniques to reduce cost:

• Streaming SSR: the server sends HTML in chunks, and the browser renders progressively instead of waiting for the entire page.
• Progressive / Selective Hydration: hydrate critical parts first (e.g., the portion the user is currently viewing).
• Islands Architecture: most of the page is static HTML, only a few interactive "islands" require JavaScript (Astro, Qwik).
• RSC (React Server Components): components run on the server, no JavaScript is sent to the client for that part.

Flashcards: quick review of concepts

Core Web Vitals — 3 metrics to remember.

Optimal levers — categorized by type.

Code splitting and lazy loading are techniques used to optimize the loading performance of web applications. Code splitting allows you to break your application into smaller chunks, which can be loaded on demand rather than all at once. This reduces the initial load time and improves the user experience. Lazy loading is a strategy that delays the loading of non-essential resources until they are needed. This means that components or modules are only loaded when they are required, further enhancing performance and reducing the amount of data that needs to be transferred during the initial load. Together, these techniques help in creating more efficient and responsive applications.

Instead of sending all JavaScript at once, only load the necessary parts. This is one of the most effective optimizations for FCP/LCP.

// Split bundle by route — load only when needed
const Dashboard = React.lazy(() => import('./Dashboard'));

function App() {
  return (
    <Suspense fallback={<Skeleton />}>
      <Dashboard />
    </Suspense>
  );
}

List Virtualization — a key technique for handling long lists.

Rendering 10,000 rows at once will kill performance. Virtualization only renders items within the viewport (plus a small buffer), reusing DOM elements when scrolling.

Popular libraries: react-window, react-virtuoso, @tanstack/virtual.

Flashcards Performance

REST vs GraphQL REST (Representational State Transfer) and GraphQL are two different approaches to building APIs. REST is an architectural style that uses standard HTTP methods (GET, POST, PUT, DELETE) to interact with resources. Each resource is identified by a unique URL, and the server responds with the entire resource representation. This can lead to over-fetching or under-fetching of data, as clients may receive more or less information than needed. GraphQL, on the other hand, is a query language for APIs that allows clients to request exactly the data they need. It provides a single endpoint and enables clients to specify the structure of the response. This reduces over-fetching and under-fetching issues, as clients can tailor their requests to their specific requirements. In summary, REST is resource-oriented and can lead to inefficiencies in data retrieval, while GraphQL is query-oriented and offers more flexibility in data fetching.

Pagination: 3 strategies

Handling Race Condition in search/autocomplete.

When a user types "rea" quickly → "react", the request for "rea" may arrive AFTER "react" and overwrite the correct result. Solution:

let controller;
async function search(query) {
  controller?.abort();           // Cancel the old request.
  controller = new AbortController();
  const res = await fetch(`/api?q=${query}`, {
    signal: controller.signal
  });
  return res.json();
}

Combine with debounce (~300ms) to reduce the number of requests, and check "whether this request is still the latest" before calling setState.

Resilience: retry, timeout, backoff

• Timeout: do not leave requests hanging indefinitely — cancel after N seconds.
• Retry with exponential backoff: retry at 1s → 2s → 4s to avoid overwhelming the server.
• Idempotency: For POST requests that create data, use an idempotency key to retry without creating duplicates.
• Graceful degradation: serve stale cache / display user-friendly error messages instead of a white screen.

State classification — decision diagram

Four types of state to distinguish:

One-way Flux / Redux

One-way data flow makes debugging easier: every state change goes through action → reducer, so we always know "why the state changed."

Principles of Component API Design

• Single Responsibility: each component does one thing well.
• Composition over configuration: prioritize composing smaller components rather than a single massive component with 30 props.
• Controlled vs Uncontrolled: allow both when appropriate (value + onChange, or defaultValue).
• Sensible defaults: works immediately with minimal props.
• Default accessibility: ARIA roles and focus management are built-in.

Example: design an API for the Autocomplete component.

interface AutocompleteProps<T> {
  // Data & How to Retrieve It
  fetchOptions: (query: string) => Promise<T[]>;
  // Custom display
  renderOption?: (item: T) => ReactNode;
  getOptionLabel: (item: T) => string;
  // Behavior
  debounceMs?: number;        // default 300
  minChars?: number;          // default 1
  // Controlled
  value?: T | null;
  onChange?: (item: T | null) => void;
  // State
  loading?: boolean;
  emptyMessage?: string;
}

The Compound Components pattern is a design pattern in React that allows you to create components that work together as a single unit. This pattern enables better composition and flexibility by allowing child components to communicate with their parent component without needing to pass props explicitly. It promotes a more intuitive API and enhances the reusability of components.

Allows users to compose child components flexibly, sharing state implicitly via Context.

<Tabs defaultValue="profile">
  <Tabs.List>
    <Tabs.Trigger value="profile">Profile</Tabs.Trigger>
    <Tabs.Trigger value="settings">Settings</Tabs.Trigger>
  </Tabs.List>
  <Tabs.Panel value="profile">...</Tabs.Panel>
  <Tabs.Panel value="settings">...</Tabs.Panel>
</Tabs>

Client-side cache layers

Choose client-side storage.

Cache invalidation strategy

Stale-while-revalidate (core of SWR/React Query): immediately returns stale data to the UI for smoothness, while fetching in the background to update → users see fast results and always have fresh data.

Optimistic UI for a real-time feel.

When liking a post, update the UI immediately before the server responds, then rollback if an error occurs. The user experiences instant feedback even with network latency.

Core Accessibility Checklist