Command Palette

Search for a command to run...

Hectal
Phase 25Advanced26 of 28 in React

Frontend System Design with React

Design a frontend the way senior interviews and real teams expect: RADIO, building blocks, six full designs with live React slices, and a checklist.

Frontend system design is planning a whole product's client side before you write it: what it must do, how the screen splits into components, where every piece of data lives, what the server sends, and how it stays fast, accessible and safe. Senior interviews have a round for it ("design a news feed", "design Google Docs"), and real teams write the same thing as a design doc before a big feature.

This phase gives you a method (RADIO: Requirements, Architecture, Data model, Interface, Optimisations), the building blocks every design reuses, and then six complete designs: a news feed, an autocomplete, a chat app, a shop with checkout, a collaborative editor and a data dashboard. Each one has requirements with numbers, a Mermaid architecture diagram, a component tree, TypeScript types, the API, the deep dives an interviewer pushes on, and a live React slice of the hardest part, built with fake APIs and sockets so you can run it.

It builds on everything before it: data fetching (Phase 14), state at scale (Phase 15), performance (Phase 16), accessibility (Phase 18), rendering strategies and Server Components (Phase 20), security (Phase 21), architecture (Phase 22), production (Phase 23) and the frontend patterns of Phase 24. The backend half of each design (databases, caches, CDNs, WebSocket servers) lives in the System Design course at /system-design.

0/9 · 0%
9 topics ~4 h 28 code blocks & diagrams
Start with the first topic
1
25.1

How to Approach Frontend System Design

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.

26 min 1 diagram 3 code practice

2
25.2

Frontend Architecture Building Blocks

Every frontend design is assembled from the same blocks: a rendering choice, a component tree with state in the right places, a server cache next to a small client store, routes split into chunks, one API layer, a loading and error strategy, a design system and monitoring.

27 min 3 code practice

3
25.3

Design a News Feed

A news feed is an endless, personalised list that keeps growing at the top while the user scrolls down; the design rests on cursor pagination, a normalised store, a virtualised list, a new-posts banner instead of jumping content, optimistic likes and careful image loading.

30 min 3 code practice

4
25.4

Design an Autocomplete / Typeahead

An autocomplete suggests results while the user types; the design is about sending few requests (debounce), answering repeats from an LRU cache, never showing stale answers (race conditions), a correct ARIA combobox for keyboard and screen readers, and choosing server ranking or client filtering.

28 min 3 code practice

5
25.5

Design a Chat Application

A chat client keeps a live two-way connection, shows your message instantly and then confirms it, orders messages by the server's sequence number rather than by arrival, keeps the scroll where the reader expects, counts unread messages, queues sends while offline and shows who is online and typing.

31 min 3 code practice

6
25.6

Design an E-commerce Product and Checkout Flow

A shop's frontend must be found by search engines, load fast on phones, keep filters shareable in the URL, keep one cart across tabs and devices, make checkout forms easy and correct, keep card data away from your own code, and measure every step of the funnel.

29 min 3 code practice

7
25.7

Design a Collaborative Editor or Whiteboard

In a collaborative editor several people change one document at once, so clients send small operations instead of whole snapshots, and the system needs a rule (server ordering with OT, or CRDTs) that makes every screen end up the same, plus presence cursors, per-user undo and continuous autosave.

29 min 3 code practice

8
25.8

Design a Data Dashboard

A dashboard is a grid of independent widgets that each load, refresh, fail and render on their own; the design is about a shared query cache, polling or streaming at sensible rates, charts that draw thousands of points cheaply, virtualised tables, filters and time ranges in the URL, and permissions enforced on the server.

29 min 3 code practice

9
25.9

Cross-Cutting Concerns: Performance, Accessibility, i18n and Security at Design Time

Some requirements touch every screen: performance budgets tied to Core Web Vitals, accessibility to WCAG 2.2 AA, localisation for many languages and directions, security boundaries (XSS, CSP, auth), and observability; deciding them at design time is cheap, retrofitting them is not, so bring the same checklist to every design.

27 min 3 code practice

Practise this phase

Hands-on exercises: write the code, see your page live, and press Check to have it tested automatically.

1

Normalise a feed and update one entity

The fake API response in the starter gives every post its own copy of its author. Write normalise(posts) so the state is { postsById, usersById, ids }: each post stores authorId instead of an author object, and each user is stored once.

Intermediate
2

A cursor-paginated feed without duplicates

fetchPage(cursor) in the starter returns { items, nextCursor } after 50 ms. Start with fetchPage(null); pass the returned nextCursor to get the next page. nextCursor is null on the last page. The server sometimes repeats the last post of the previous page.

Intermediate
3

Shop filters that live in the URL

The starter renders products inside a MemoryRouter that starts at /shop?page=2, and shows the current query string in <code id="url">.

Advanced
4

Optimistic chat send with retry

sendApi(clientId, text) in the starter answers after 100 ms. It fails the first attempt of any message containing flaky, and it stores each clientId only once (it's idempotent).

Advanced
5

A cached, race-free, accessible autocomplete

searchApi(q) in the starter returns up to 5 words starting with q. Two-letter queries are slow (400 ms), longer ones fast (100 ms), so answers can arrive out of order. Each call is recorded in window.searchCalls.

Advanced