FSD Frontend System Design

Part VI — The Blueprint · Lesson 11.1

HLD Overview

In one lineOne frame, eight steps, forty-five minutes — the structure is what's being graded, not the trivia.

Where you've seen itTwo candidates propose the same architecture. The one who spent five minutes on requirements first is the one who gets the offer.

  • Time16 min
  • DiagramThe 8-step frame + the 45-minute time budget
  • Chapter11 · High Level Design

Diagram

diagram
THE 8-STEP FRAME — every lesson in this chapter follows it

  1. REQUIREMENTS    functional · non-functional · explicitly out of scope
  2. SCALE NUMBERS   DAU · payload size · RPS · growth · device mix
  3. ARCHITECTURE    client ─ CDN ─ BFF ─ services      (box diagram)
  4. DATA MODEL      entities · API contracts · pagination shape
  5. COMPONENT TREE  screen breakdown                    (tree diagram)
  6. DEEP DIVES      the 2 genuinely hard problems in THIS app
  7. CROSS-CUTTING   perf · a11y · security · offline · monitoring
  8. TRADE-OFFS      what you chose, and what you gave up
diagram
THE 45-MINUTE BUDGET — where candidates lose time

   0───5────────15──────────────30─────────40────45
   │    │        │               │          │     │
   │ REQ│  ARCH  │   DEEP DIVE   │  CROSS   │ Q&A │
   │ +  │  DATA  │   (the part   │  CUTTING │     │
   │scale│ TREE  │   they grade) │          │     │

   ✗ 20 minutes on requirements  → no time to show depth
   ✗ 0 minutes on requirements   → you design the wrong system
   ✓ 5 minutes, then move, and revisit scope when it matters
diagram
FRONTEND HLD ≠ BACKEND HLD

  they ask about              not about
  ─────────────────────────────────────────────────────
  rendering strategy (5.6)    database sharding
  state + caching (6.9)       consensus algorithms
  component boundaries        message queue internals
  transport choice (2.7)      load balancer algorithms
  perceived performance       replica placement

  You may mention backend concerns — briefly, to show you know
  the boundary — then return to the client.

How it works

  1. Ask before designing. Who uses it, on what device, what's the one thing it must do well, and what's explicitly excluded.
  2. Get one number. DAU, items per screen, update frequency — a single figure changes the design and shows you think in scale.
  3. Draw the boxes, then the component tree. Talking without drawing is the most common failure mode.
  4. Pick the two hard problems yourself. Every app in this chapter has them named for you.
  5. Close with trade-offs. "I chose X, which costs me Y, and I'd revisit it if Z" is the single highest-signal sentence in the interview.

Trade-offs

DoDon't
Drive the structure out loudWait to be asked the next question
State assumptions and move onStall waiting for perfect requirements
Draw, then talkTalk for ten minutes with a blank board
Name what you're skippingPretend you covered everything

RADIO (Requirements, Architecture, Data, Interface, Optimisation) is the same idea in five letters — covered in 12.13. Use whichever you'll remember under pressure.

Interview angle

"Design Instagram's frontend."

  • Scope out loud first: feed and upload for mobile web, excluding stories, DMs, and reels — then confirm.
  • Give a number: 500M DAU, ~30 posts per session, images 200KB after transform.
  • Then follow the frame, and reserve the middle 15 minutes for the two deep dives, which is where the grading actually happens.

Recap

  • Eight steps, in order, every time — the frame is the skill.
  • Five minutes scoping, fifteen minutes of depth, always a trade-off close.
  • Frontend HLD is about rendering, state, transport, and components — not databases.