Skip to content

Frontend system design

Frontend system design with the RADIO framework: components, data, rendering, real-time, scale and security, then ten worked design prompts.

25 lessons

Framing the round (R, A and I of RADIO)

  1. 1RADIO: driving a frontend design roundOutline all five phases on the client side, then spend the protected minutes on the few areas this product needs, opened unasked.
  2. 2Component decomposition and client data modelShape the data so an update replaces one record, and shape the components so only that record's readers run.
  3. 3API contract from the client's sideAgree what the screen can render, recover, continue and reconcile before choosing its endpoint shape.

Rendering and data (D of RADIO)

  1. 4Choosing a rendering strategy per routeDecide each route by who reads its first HTML, whether everyone gets the same page, and how fresh it must be.
  2. 5Client-side server-state cacheThe key is the identity, staleTime decides when to ask again, and gcTime decides how long nobody may need an entry before it goes.
  3. 6State ownership taxonomyEvery fact has one owner, as close to its readers as it can be; anything computable from owned state is computed, never stored.

Real-time, time and resilience

  1. 7Real-time delivery: polling, SSE and WebSocketStart with who needs to speak, then choose how much connection state the network and client can keep.
  2. 8Server-authoritative time and client timersCalibrate a server-time anchor; redraw the deadline from elapsed time, not callback counts.
  3. 9Durable client retries and cancellationKeep one identifiable command until its outcome can be reconciled.

UI at scale (O of RADIO)

  1. 10Pagination and list virtualizationA windowed list trades a flat DOM for rows that exist only as data: search, measure and focus must then be handled by you.
  2. 11Design systems and component APIsComponents read roles, not values; primitives carry behaviour; the version number says what may break.
  3. 12Internationalization architectureLocalization is architecture: whole messages per locale, plural rules per language, Intl for every format, and one locale carried by the URL.
  4. 13Client side of large uploadsA large upload is numbered parts and their ETags: the client resends what lacks one, completes in order, and the API never carries the bytes.

Operating and securing the frontend

  1. 14Frontend observability and field performanceMeasure real visits, split them by who had them, and give every report its release and its trace.
  2. 15Client trust boundary: what the browser can proveThe browser is the user's; the server decides every action from its own records.

Frontend design prompt bank

  1. 16Design prompt: a typeahead search boxPut numbers on requests, latency and bytes first; every cache and reuse rule must leave each list exactly what the service would send.
  2. 17Design prompt: a news feedA feed client protects the reader's place: new posts wait behind a pill, images land in reserved boxes, and only cards near the screen exist.
  3. 18Design prompt: a chat / messaging UIA chat client trusts two numbers: the id it makes at the tap, and the sequence the server gives each conversation.
  4. 19Design prompt: a real-time dashboardA live dashboard is a snapshot plus numbered changes, drawn once per frame, with each tile showing how old it is.
  5. 20Design prompt: image and video uploaderPut numbers on size, link, drops and deadline first; part size, start time, URL batches and what survives a reload follow from them.
  6. 21Design prompt: product page and checkoutCache by freshness, price at the server, and keep one payment attempt and its key on the order, where every resend finds it.
  7. 22Design prompt: collaborative editor (lite)Send changes that know where they belong, keep presence apart, and keep what history needs.
  8. 23Design prompt: video playerPut numbers on the first frame, stalls and captions first; segments, the ladder, the bitrate rule and the buffer follow from them.
  9. 24Design prompt: calendar and bookingStore instants with their zone, keep series as wall times, and let the server decide who gets the seat.
  10. 25Design prompt: the ExamHall candidate appFour guarantees: the paper is sealed and local before 09:00, no answer is lost or overwritten, outages are survivable, and every locale saves one value.