Frontend System Design: From Client-Server to Planet Scale

THE CONCEPTS

The mental models, one by one

1. 01

   Functional vs Non-Functional Requirements

   Functional requirements are what the system does: view products, add to cart, pay. They come straight from user stories, and from them you sketch the low-fidelity mockup.

   Non-functional requirements are how it does it: performance, scalability, availability, accessibility, maintainability, security. This is where system design actually starts.

   Your seniority shows in the questions you ask: expected traffic? Geography? Device split? Traffic spikes on Prime Day? Accessibility legislation?

   theSeniorDev

   User storiesLow-fi mockupSix NFRs
2. 02

   Essential State & the Irreducibility Test

   State comes from exactly two places: user interaction and data fetching. Condense it to the essential state — the minimum data that can render the UI.

   Then run the irreducibility test: remove any state variable and the UI must break. If it doesn't, that variable was derived state pretending to be essential.

   theSeniorDev

   Essential stateDerived stateLoading / error / data
3. 03

   Lifting State: The Three Altitudes

   Local state, shared local state, global state. Place state as low as possible, as high as necessary.

   Pagination looks local until you realize the API request needs it — so it lifts to sit beside the product-fetching state. Brand filters follow. Auth is genuinely global.

   This discussion — where does each piece of state live and why — is usually the first thing the interviewer probes after the mockup.

   theSeniorDev

   Component treeProp drillingReducer pattern
4. 04

   API Modeling & the Underfetching Problem

   Model your entities as REST resources: /products, /products/:id/price, ratings, reviews, delivery. Prices and ratings change on their own schedules — they're separate entities, not fields.

   Filtering, sorting and pagination are query parameters on the collection endpoint.

   Count the requests: one page view, five backend calls. That's underfetching, and it's the setup for the BFF and GraphQL later.

   theSeniorDev

   REST resourcesQuery paramsUnderfetching
5. 05

   Back-of-the-Envelope Analysis

   2.11 billion monthly visits means nothing. Break it down: per week, per peak day, per peak hour — about 21 million visits an hour, times 6.8 page views each: ~136 million page views per hour.

   The exact numbers matter less than the reasoning. Going from a fuzzy marketing number to requests-per-second with your interviewer is the skill being tested.

   theSeniorDev

   Traffic estimationPeak-hour mathRequests per second
6. 06

   Web Performance as an SLI

   An SLI is a service level indicator — a quantified non-functional requirement. On the frontend, your SLIs are the Core Web Vitals: LCP and CLS for the load, INP for responsiveness.

   First question about any UI: how static or dynamic is it? Media sites, e-commerce, social feeds and enterprise SaaS sit on a spectrum, and everything downstream depends on where you land.

   theSeniorDev

   SLICore Web VitalsStatic vs dynamic spectrum
7. 07

   Latency & the CDN (Scale Level 1)

   Light through fiber crosses the US in ~9ms. Real networks take 140-160ms per round trip through the switches, and HTTPS needs about four round trips before a byte of content moves. That's ~600ms just to say hello.

   The fix is not a faster server — it's distance. Replicate static assets to edge locations near users: the CDN. Free extras: HTTP caching, compression, image format conversion.

   theSeniorDev

   Network latencyTCP + TLS handshakesEdge locations
8. 08

   SSR, Edge Compute & Distributed Data (Scale Levels 2-3)

   Client-side rendering gives dynamic pages the white screen of death. SSR pre-renders on the server — but now every dynamic route pays the latency tax again.

   So distribute the compute: edge functions running close to users. Then distribute the reads: read-only database replicas next to the edge functions.

   That's the CAP theorem trade: with partitioning, you give up strict consistency. Fine for social feeds. Unacceptable for payments. Say which one your use case is.

   theSeniorDev

   Edge functionsRead replicasCAP theoremHydration
9. 09

   Scale by Eliminating Requests

   The best way to serve more requests is to serve fewer. Find data that's read far more than it's written — product images, titles — and cache it aggressively.

   Pricing and delivery estimates change constantly; cache those carefully or not at all. The read/write ratio decides the policy.

   theSeniorDev

   Read-heavy dataCache policiesHTTP caching
10. 10

    API Gateway, BFF & GraphQL (Scale Level 4)

    An API gateway is a reverse proxy that centralizes the repetitive work — HTTPS termination, auth, caching — so microservices behind it stay simple.

    The BFF is a reverse proxy built for one client, owned by the frontend team. It implements the facade pattern: the frontend asks for a view, the BFF assembles it from microservices. One per client if mobile and desktop diverge.

    Add GraphQL to the BFF and five REST calls become one query, with the frontend choosing exactly the fields it needs — mobile data budgets say thank you.

    Then scale the BFF horizontally behind a load balancer (round robin, least connections). That's where the traffic concentrates.

    theSeniorDev

    API gatewayBFFGraphQL resolversLoad balancing
11. 11

    Conway's Law & Micro-Frontends (Scale Level 5)

    Organizations ship their communication structure. A 45-person daily standup is an architecture problem wearing a calendar invite.

    Split the team, and to split the team, split the system: micro-frontends — independent apps on independent domains, composed at runtime by a shell, released independently.

    Jeff Bezos' rule: if two pizzas can't feed the team, it's too large.

    theSeniorDev

    Conway's lawTwo-pizza teamsIndependent deploys
12. 12

    Design Systems & Monorepos (Scale Levels 6-7)

    Independent apps drift apart visually. A design system — an internal npm package of shared components — keeps visual cohesion and stops every team rebuilding the same date picker.

    A monorepo keeps them coherent technically: shared lint rules, TypeScript config, build tooling, one deployment pipeline shipping Docker images. Engineers can switch teams without learning a new universe.

    theSeniorDev

    Design systemMonorepoShared tooling