Frontend System Design Interview

Prerequisites

Seniority is a weak readiness signal in this round, because frontend experience varies enormously in what it touched: two engineers with the same years can have shipped very different surfaces. Prerequisite mastery is the signal that works. Answer every Quick check in under a minute. Two or more misses means start with the linked material rather than with Module 1.

Time budget

Learning objectives

Each objective is tested by exactly one numbered item in the mastery check, and the numbering matches: objective 1 is tested by mastery item 1.

1. Classify a frontend prompt as application-scale or component-scale within the first sixty seconds, naming the two signals in the interviewer's wording that decided it, and stating the single clarifying question that settles a tie.
2. Choose a rendering strategy from client, server, static, incremental, streaming and islands for a stated first-render budget, personalisation level and device profile, naming the number that decides it and the specific cost the rejected strategy would have carried.
3. Derive a delivery budget from a stated device and network profile, giving JavaScript bytes allowed on the critical path, a first-render target and an interaction-response target, showing the arithmetic that converts bytes into milliseconds at the stated bandwidth.
4. Specify the public interface of an interactive component, covering controlled versus uncontrolled state, the state machine, and the keyboard and focus contract, to the point where a second engineer could implement it without asking you a behavioural question.
5. Separate a screen's state into client, server-cache and shared categories, and state for every server-cache entry its cache key, its staleness tolerance in seconds and the event that invalidates it.
6. Diagnose a described interaction-latency regression into exactly one named cause from long task, render cascade, unshipped code split, blocking third party or layout thrash, and name the single measurement that confirms it, in under three minutes.
7. Rewrite a mid-level frontend answer into a staff-level one by adding a performance budget enforced in continuous integration, a conformance target with its testing method, a rollout and kill-switch plan, and one degradation path, annotating what each addition changed about a decision already made.

Warm-up retrieval

Three to five minutes. Answer out loud or in writing before you open anything else. Retrieval beats rereading, and a visible answer quietly converts one into the other.

Q1. From the hub's round router: name two signals inside the first minute that tell you this is a frontend design round rather than a generalist distributed-systems round wearing a frontend title.

Q2. From the trade-off atlas on the hub, several pages back: state the client rendering versus server rendering rule, and name the two numbers that decide it.

Q3. The hub states one hard rule about when a number may appear in your answer, and one situation in which capacity math is theatre. State both, and say what replaces server-side request-rate math in a client-side round.

Module map

+--------------------------------------------+
| FRAME                             M1 to M3 |
| which of the two rounds you are in, the    |
| clock, and budgets for an interface        |
+------+----------------------+--------------+
       |                      |
       v                      v
+------------------+   +---------------------+
| RENDER           |   | COMPONENT           |
| M4 strategy      |   | M6 public API and   |
| M5 server and    |   |    state machine    |
|    client line   |   | M7 accessibility    |
|                  |   |    contract         |
+------+-----------+   +------+--------------+
       |                      |
       +--------------+-------+
                      v
+--------------------------------------------+
| DATA                             M8 to M10 |
| state split three ways, HTTP and browser   |
| caching, transports and offline queues     |
+---------------------+----------------------+
                      v
+--------------------------------------------+
| SPEED AND REUSE                 M11 to M13 |
| metrics, budgets in CI, design systems,    |
| micro-frontends and when to refuse them    |
+---------------------+----------------------+
                      v
+--------------------------------------------+
| HARDEN AND JUDGE                M14 to M18 |
| browser security, locales, testing and     |
| rollout, observability, level calibration  |
+--------------------------------------------+

Caption: six clusters and their reading order. Frame splits into
two branches because this course trains two round formats: Render
is the application branch, Component is the widget branch. Both
rejoin at Data, because state and caching decide either one. Data
feeds Speed and Reuse, which feeds Harden and Judge, where mid
and staff answers separate. Arrows run prerequisite to dependent.

Low ends total 540 minutes, high ends total 720. That is the 9 to 12 reading hours in the time budget above.

The delivery clock for this round

This page takes a position on how the round is lost, and its whole structure follows from that position. The failure is rarely a missing fact. It is naming libraries, drawing a component tree that would fit almost any prompt, and never committing to a rendering strategy, a byte budget, a keyboard model or a way of being wrong. This round is also the only one in the section with two genuinely different clocks, because "design a news feed" and "design an autocomplete" want their minutes spent in different places.

The 45 minute application round

The phases sum to 45 by construction: 2 plus 6 plus 3 plus 8 plus 9 plus 10 plus 7.

The 45 minute component round

Same slot, very different shape. There is no capacity phase and no architecture diagram. The public interface is the artefact, and roughly half the clock belongs to behaviour rather than structure.

These sum to 45: 2 plus 5 plus 7 plus 7 plus 8 plus 8 plus 8.

The 60 minute rounds

The application column sums to 60: 2 plus 8 plus 4 plus 9 plus 11 plus 16 plus 7 plus 3. The component column also sums to 60: 2 plus 6 plus 9 plus 8 plus 9 plus 10 plus 10 plus 6. In both cases the extra 15 minutes buys depth and a rollout story. It does not buy more boxes.

The first two minutes

Four sentences, in this order. Rehearse them once so they run without attention and you can spend yours on listening.

1. "Let me restate it: users do X on this surface, and the thing I think is hard is Y." (If you cannot name a hard part, that is your first clarifying question.)
2. "Before I draw: do you want the whole surface, or this as a reusable component with a public API?" (This is the highest-value eight seconds in the round.)
3. "I am going to spend about six minutes on requirements and budgets, then draw it, then break it on purpose." (You just told them your clock, which reads as control.)
4. "Stop me if you want depth somewhere specific rather than coverage." (Interviewers take this invitation more often than candidates expect.)

Declaring what you are skipping

Skipping in silence reads as not knowing. Skipping out loud reads as prioritising. The pattern: name it, say why it cannot change a decision in the next twenty minutes, say in one sentence what you would do if it were in scope.

• "I am not designing the API. I will assume a cursor-paginated endpoint, and I will state what I need from it: stable ordering under inserts, and a total count only if the design turns out to need one."
• "I am skipping the theming layer. It does not touch the rendering strategy or the data path, and at this scope it is a token naming exercise rather than an architecture one."
• "I will cover analytics in one line: it goes on an idle callback, and it is the first thing I delete if the third-party byte budget is blown. Tell me if you want more."

Checking in without sounding unsure

A weak check-in asks for reassurance. A strong one offers a fork, so the interviewer routes you and you keep driving.

Two check-ins in a 45 minute round is about right: one after v0, one before the deep dive. Past four, you have handed over the driving seat, which is the thing being graded.

How the split shifts by level

Read the columns rather than the cells. Mid level spends its minutes proving a working interface could be built. Senior spends them proving the rendering, state and accessibility decisions were chosen deliberately against numbers. Staff spends them proving the design is reachable from the codebase that exists, operable when a third-party script goes slow, and cheap enough that nobody reverts it next quarter.

Module 1. Scope and honesty: the two question formats

Time: 20 to 30 minutes reading, 10 to 15 minutes practice.

1a. Predict first

Four interviewers open four rounds. All four invites said "Frontend System Design". Read the opening lines before anything else on this page.

The two formats, side by side

One title covers two rounds that share almost no rubric. Preparing only for one is the most expensive mistake available on this track, because it costs weeks and is invisible until the round starts.

Two formats you should also expect, and neither is on the invite

• The disguised backend round. The interviewer keeps asking about the database behind the feed. The rubric in their head is server capacity. Steer once, explicitly, then follow: "I can design the client, or I can design the service behind it. Which is scored today?" If they want the service, Modern System Design is the material, and saying so out loud costs you nothing.
• The diagnostic round. You are handed a running system and a regression, as in P4. There is no greenfield design phase. The deliverable is an ordered measurement plan, one cause, and the smallest change that moves the number.

How to tell inside sixty seconds

Four tells, in order of reliability.

1. Reuse language. "Design system", "component library", "used by N teams", "reusable", "publish it as a package". Any one of these makes it component scale, because the deliverable is a contract other people depend on.
2. The article and the noun. "The feed", "our checkout" is a specific product surface, so application scale. "A date picker", "an uploader" is a category, so component scale.
3. Whether the data source is described. If the interviewer describes endpoints, payload shapes or an existing gateway, they have drawn the boundary for you and everything interesting is inside the client.
4. Whether a constraint arrives unprompted. "Our users are on low-end Android devices" or "this has to work at 200 rows per second" signals application scale with a budget already chosen for you.

The routing diagram

          first two sentences of the prompt
                        |
        +---------------+---------------+
        |                               |
  names a product              names a widget or
  surface or a page            a reusable primitive
        |                               |
        v                               v
+------------------+          +--------------------+
| application      |          | component scale    |
| scale            |          | API + state chart  |
+------------------+          +--------------------+
        |
   does a system
   already exist
        |
   +----+-----+
   |          |
   v          v
+--------+ +----------------+
| green  | | diagnostic:    |
| field  | | measure first  |
+--------+ +----------------+

Caption: routing the opening of a frontend round to one of three
deliverables. Reuse language sends you right; an existing system
sends you to the diagnostic branch, where measurement precedes design.

On which companies favour which format

We are not going to publish a company-to-format table, and the reason is the point of this section.

What you can do instead, all of it checkable by you:

• Read the job description for structural words. "Design system", "component platform", "web platform", "developer experience", "UI infrastructure" predict component scale. "Product engineer", "growth", "feature team", "consumer web" predict application scale. This is inference about the work, not a claim about a company.
• Ask the recruiter two questions. "Is the frontend design round scoped to the client, or does it include the service behind it?" and "Is it usually a product surface or a single component?" Both are ordinary scheduling questions and recruiters answer them.
• Read the interviewer's public profile if you are given a name. Someone who works on a component library is unlikely to hand you a feed prompt.

1d. Worked example

The invite says: "Frontend Engineer, four rounds. Frontend System Design (60 min), Coding: DOM and async (45 min), Frontend Deep Dive (45 min), Behavioural (45 min). Your design interviewer works on the Web Platform team."

Block 1. PURPOSE: convert a round list into a list of artefacts, because artefacts are what I can rehearse.

Three technical rounds, three different outputs. The design round wants a design artefact. The coding round wants working code against a DOM API. The deep dive wants spoken mechanism at the level of "what does the browser actually do here". I write three words at the top of my plan: artefact, code, mechanism.

The strongest signal in the email is "Web Platform team". That is infrastructure, not product. It shifts my expectation toward component scale, or toward an application prompt where the interesting part is the boundary rather than the feature.

The error most readers make here is reading "Frontend Engineer" and rehearsing a news feed, because a feed is the prompt that free material practises most. The team name overrides the job title every time.

Block 2. PURPOSE: decide what I will deliberately not prepare, because preparation is subtraction.

Given a platform team, I drop three areas entirely: marketing-page search visibility, analytics dashboards, and anything that turns into a product-sense conversation. I keep and deepen four: public API design for a component, the accessibility contract, bundle and boundary economics, and version skew across consumers.

That reallocation is roughly six hours of study moved, not added. A platform interviewer asking "what happens when a consumer upgrades and their markup breaks" is a question no amount of feed practice answers.

The error most readers make here is additive preparation: they bolt component material on top of a full application syllabus and arrive having half-rehearsed both.

Block 3. PURPOSE: buy information cheaply, because two sentences from a recruiter beat two hours of inference.

I send one message: "For the 60 minute design round, is it usually a product surface or a single reusable component? And is the service behind it in scope, or is the round scoped to the client?"

If the answer is "single component", my whole rehearsal changes: I practise drafting a prop table under time pressure, not drawing architecture. If the answer is "product surface, client only", I practise the rendering and caching derivation instead.

Block 4. PURPOSE: rehearse an opening that works for either format, because the email did not settle it.

I write and say out loud: "Before I start, one question that changes how I spend the hour: is this a product surface, where I should design the client architecture and its budgets, or a single reusable component, where I should design the public API and the interaction model? I have a plan for both. If you have no preference I will assume the first and say what I am dropping."

The error most readers make here is improvising the opening, then discovering at minute twenty that they drew architecture for a component prompt.

Result. The reply was: "Component prompt, and she cares a lot about accessibility." That moved the final hours from rendering strategy to focus management and the authoring patterns in Module 7, which is exactly where the round went.

1e. Fade the scaffold

Faded example 1. The invite says: "Senior Frontend Engineer, Payments. Rounds: Frontend System Design (60), Coding (60), Behavioural (45). The design interviewer is the tech lead for the checkout surface." Blocks 1 to 3 are given. Produce block 4.

• Block 1: artefacts are a design artefact, code, and a behavioural narrative. "Checkout surface" is a product surface, so application scale is the default assumption.
• Block 2: I drop design-system governance, micro-frontends and heavy visualisation. I keep form correctness, error and retry semantics, idempotent submission from the client, and third-party script risk on a payment page.
• Block 3: I ask whether the payment provider integration is in scope, because an embedded provider frame changes the security and state model completely.

Faded example 2. The invite says: "Frontend Engineer, Data Platform UI. Rounds: Frontend System Design (45), Coding (45), Behavioural (45). No further detail." Blocks 1 and 2 are given. Produce blocks 3 and 4.

• Block 1: three artefacts. Only 45 minutes for design, so about 40 working minutes, which means one deep dive rather than two.
• Block 2: "Data Platform UI" points at grids, charts and large result sets, so I keep virtualization, interaction latency under load, and streaming or paginated result handling. I drop marketing-page concerns entirely.

1f. Check yourself

Q1. An interviewer says: "Design a file uploader." You ask no questions and start drawing a client, a chunking layer and a server. What did you just get wrong, and what was the one question worth asking?

Q2. Twenty minutes into an application-scale round, the interviewer says "assume everything renders instantly and the network is free". What just happened, and what do you do?

1g. When not to use this

Format triage is a preparation tool, and it is over-applied more often than under-applied.

Module 2. The delivery clock for a frontend round

Time: 25 to 35 minutes reading, 15 to 20 minutes practice.

2a. Predict first

Below is the generalist clock from the hub, for 40 working minutes.

The two clocks

Both clocks assume a 45 minute slot loses about 5 minutes to introductions, tooling and your questions at the end, leaving 40 working minutes, and a 60 minute slot loses about 8, leaving 52. Those two deductions are assumptions, and they are reasonable because nearly every remote round spends time on hellos, screen sharing and closing questions. Adjust once you see how your interviewer runs the first two minutes.

Application-scale clock.

The sums: 3 plus 6 plus 4 plus 8 plus 8 plus 7 plus 4 is 40, and 4 plus 7 plus 5 plus 10 plus 11 plus 10 plus 5 is 52.

Component-scale clock. Same working minutes, spent on entirely different things.

The sums: 4 plus 7 plus 7 plus 6 plus 7 plus 4 plus 5 is 40, and 5 plus 9 plus 9 plus 8 plus 9 plus 6 plus 6 is 52.

The shape, drawn

Application scale, 40 working minutes
+-----+--------+-----+--------+--------+-------+-----+
|Scope|Reqs+bud|API  | V0     | Break  | Dive  |Wrap |
| 3   | 6      | 4   | 8      | 8      | 7     | 4   |
+-----+--------+-----+--------+--------+-------+-----+
0     3        9     13       21       29      36    40

Component scale, 40 working minutes
+------+--------+--------+------+--------+----+-----+
|Users | API    | States | A11y | Edges  |Perf|Ver  |
| 4    | 7      | 7      | 6    | 7      | 4  | 5   |
+------+--------+--------+------+--------+----+-----+
0      4        11       18     24       31   35    40

Caption: the two clocks over the same 40 working minutes. The
application clock puts its two widest blocks after the first
drawing. The component clock has no single dominant block, and
spends 20 of 40 minutes on states, accessibility and edges.

The first two minutes, per format

Four sentences, in order, before you draw or write anything.

Application scale.

1. Restate the surface with one number attached, so a mismatch surfaces now rather than at minute thirty.
2. Name the two or three things you believe are actually hard, in client terms: bytes, interaction latency, state ownership, offline, accessibility.
3. State what you are dropping, and why it cannot change a decision in the next twenty minutes.
4. Ask the one clarifying question whose answer changes the design most, usually about device class, data volume or personalisation.

Component scale.

1. Name the consumers: "I am designing this for other teams, so the API is the thing I cannot take back."
2. Name the three call sites you will design against, including one awkward one.
3. State the two things you will treat as functional requirements rather than extras: the keyboard model and the controlled or uncontrolled contract.
4. Ask whether the component is styled or headless, because that decision changes the entire API.

Checking in without handing over the pen

A weak check-in asks for reassurance. A strong one offers a routing decision and keeps you driving.

Two check-ins in a 40 minute round is about right: one after the first artefact, one before the deep dive. More than four and the interviewer is driving, which is the thing being tested.

How the split shifts by level (component-scale round)

Same 52 working minutes, allocated differently.

Read the columns, not the cells. A mid answer is scored on whether a correct client appears at all. A senior answer is scored on the breaking point and one area of real depth. A staff answer spends at both ends: negotiating what is worth building, and stating how the thing is measured, rolled out and deprecated.

2d. Worked example

Sixty minute round, so 52 working minutes. The interviewer says: "Design an autocomplete component. We would put it in our shared library."

Block 1. PURPOSE: pick the clock out loud, because the wrong clock produces the wrong artefact and I cannot recover 20 minutes.

I hear "shared library", which is tell number one from Module 1. I say: "I am treating this as a component design problem, so I will spend most of the time on the public API, the interaction states and the accessibility contract, and only a few minutes on performance. If you would rather see the search architecture behind it, say so now."

That sentence takes twelve seconds and buys the whole plan.

The error most readers make here is starting with debouncing. Debouncing is a four-line implementation detail. Leading with it signals that you think this is a coding question.

Block 2. PURPOSE: spend the first five minutes buying constraints, because a component API is decided by its consumers, not by its features.

I ask for three call sites and I insist on an awkward one: a plain search box, a multi-select tag input inside a form, and an address field that must submit on selection. Three call sites with different shapes is exactly what forces the API to be an inversion-of-control design rather than a pile of booleans.

I write the three on the board. Everything I design from here has to serve all three or explicitly refuse one.

Block 3. PURPOSE: protect the accessibility block by scheduling it early, because it is the block that gets eaten when time runs short.

I say: "I am going to do the keyboard and screen reader contract at minute eighteen, before edge cases, because it constrains the API. If I leave it to the end it becomes a list of promises."

This is a scheduling decision that reads as seniority, and it is also true: the announcement model decides whether the component owns a status region, which is a prop and therefore an API change.

Block 4. PURPOSE: reserve the last six minutes for versioning, because on a shared component that is the only part nobody else will cover.

At minute 46 I stop adding and say: "Last thing. Three changes to this API would break consumers silently rather than loudly: changing the default of a boolean, tightening a prop type, and changing what the component announces. I would ship the first behind a codemod, the second as a major, and the third never without a flag."

Result. In a real round this ordering produces an artefact the interviewer can grade against every criterion. The candidate who spends minute 46 adding a "fuzzy matching" feature has a longer feature list and a worse rating, because features are the cheap part and a contract is the expensive part.

2e. Fade the scaffold

Faded example 1. Forty-five minute round, so 40 working minutes. Prompt: "Design the notifications panel for our web app." Blocks 1 to 3 are given. Produce block 4.

• Block 1: product surface plus a definite article, so application scale. I say so, and name that the API is assumed to exist unless told otherwise.
• Block 2: I buy two numbers, notifications per user per day and whether unread count must be exact, because those two decide polling versus a persistent connection and whether the count is derived or stored.
• Block 3: V0 is a paginated list fetched on open, with the unread count from a cheap endpoint. No real-time transport yet.

Faded example 2. Sixty minute round. Prompt: "Design a data grid for our internal tools team." Blocks 1 and 2 are given. Produce blocks 3 and 4.

• Block 1: "for our internal tools team" is reuse language, so component scale. I say so and name the awkward call site early: a grid embedded inside another scrolling container.
• Block 2: three consumers, an admin table of 200 rows, a log viewer of 2 million rows, and an editable pricing sheet of 5,000 cells.

2f. Check yourself

Q1. You are at minute 26 of 40 in an application-scale round and you have only just finished V0. Which phase do you sacrifice and which do you protect?

Q2. A component-scale interviewer interrupts at minute 8 with "what happens if the consumer renders two of these on the same page?" Do you follow the clock or the question?

2g. When not to use this

Module 3. Requirements for a user interface

Time: 30 to 40 minutes reading, 20 to 25 minutes practice.

3a. Predict first

A candidate writes this requirements list in the first five minutes of a round. Read it before continuing.

Functional requirements for a user interface

The unit of a functional requirement here is not a feature. It is a capability plus every state that capability can be in. Every asynchronous UI has five, and candidates routinely write one.

Write the list as capability plus states, and you get requirements that decide architecture:

• "The feed renders the first ten posts, with each post independently able to fail without blanking the page." That sentence rules out one giant query and points at per-item boundaries.
• "Liking acknowledges within 100 ms whether or not the server has responded." That sentence forces optimistic updates and therefore a rollback path.
• "A user who reloads mid-comment does not lose the draft." That sentence forces local persistence and rules out holding drafts only in component state.

The five budget families

A budget is a number plus the condition under which it must hold. Without the condition it is a slogan.

Budget 1: interaction latency

Two different clocks, and candidates conflate them constantly.

The practical requirement that follows: acknowledge in under 100 ms, complete when you can, and show progress if completion exceeds about one second. Acknowledging is not the same as completing, and separating them is what lets you design optimistic updates without lying about them.

Budget 2: bundle bytes

Bytes are only meaningful against a network. Pick the network first, then the budget follows by division.

Two things that budget does not include, and both are usually larger than the transfer on a low-end device:

• Parse and compile, which scales with the uncompressed size, not the compressed size. That is why the 600 KB number matters more than the 200 KB one.
• Execution, meaning module evaluation, framework boot and hydration, which is Module 5.

Budget 3: first render

First render is a sum, so it can be budgeted as one. Every row is an assumption you state, and the total is the requirement.

A budget written from those rows: "First contentful paint under 500 ms on the assumed network for a cold visit to a cacheable page." Then check it: 90 plus 30 plus 200 is 320, leaving 180 ms of headroom for CSS, which forces the CSS budget to about 36 KB. That is a requirement that decides something.

Budget 4: accessibility conformance

State a level and a test method, or it is not a requirement.

The requirement sentence: "Level AA conformance for the flows in scope, verified by a keyboard-only pass, an automated rule run in continuous integration, and one screen reader pass per interactive component." Module 7 makes each of those testable. The specification itself is published by the W3C at w3.org/TR/WCAG22.

Budget 5: supported devices and networks

"Mobile" is not a requirement. A device tier is, because each tier changes a different number.

The rule worth stating out loud: the low tier decides the JavaScript budget, and the network decides the byte budget. They are different constraints and they are often in tension, because the cheapest fix for slow execution is to ship less code, which also fixes bytes, while the cheapest fix for a slow network is caching, which does nothing for execution.

Tagging, so the interviewer can audit you

Every requirement carries one of three tags. This is the same discipline the other tracks use, and it matters more here because frontend numbers are so easy to invent.

The budget waterfall, drawn

Cold visit, cacheable page, 200 KB per second, 30 ms round trip
+--------------------------------------------------+
| target: first contentful paint under 500 ms      |
+--------------------------------------------------+
   |
   +-> +----------------------+  90 ms  DNS+TCP+TLS
   |   | connection setup     |
   |   +----------------------+
   +-> +----------------------+  30 ms  CDN hit
   |   | time to first byte   |
   |   +----------------------+
   +-> +----------------------+ 200 ms  40 KB at 200 per s
   |   | HTML transfer        |
   |   +----------------------+
   +-> +----------------------+ 180 ms  what is left
       | CSS budget = 36 KB   |
       +----------------------+

Caption: a first-paint budget as a sum. Three costs are assumed
and stated; the fourth is derived by subtraction, which is what
turns a target into a byte limit somebody can enforce.

3d. Worked example

The prompt: "Design the product listing page for our e-commerce site. A large share of our growth is in markets with slow networks and inexpensive phones."

Block 1. PURPOSE: turn the prompt into capabilities and their states, because a feature list hides four fifths of the work.

I write three capabilities and their states, not five features:

• Browse a category: ideal is a grid of products; empty is "no products in this category" versus "your filters removed everything", and those need different copy and different recovery actions; loading is a skeleton grid at the correct dimensions so nothing shifts; partial is prices missing while images are present, which I decide is not allowed to render because a price that appears late is worse than a price that appears with the card; error is retryable in place.
• Filter and sort: the interesting state is partial, because the old results are still on screen while new ones load. I decide the old list stays visible and dims, rather than being replaced by a skeleton.
• Add to basket: acknowledgement under 100 ms regardless of server latency, which forces an optimistic update and a rollback path.

The error most readers make here is listing features and moving straight to architecture. The five-state pass takes ninety seconds and produces three architectural constraints, all of which I just derived rather than asserted.

Block 2. PURPOSE: pick the two budgets that will actually decide the architecture, because five budgets on a whiteboard is a checklist and two is a design.

The prompt gave me one thing: slow networks and inexpensive phones. That is GIVEN. So the two budgets that decide everything here are bytes on the critical path and execution time on the low tier. Interaction latency matters, but nothing in this page is animation-heavy. Accessibility conformance is a requirement I will state and design to, but it does not fork the architecture between two candidate designs, so it is not one of the two.

I say this out loud, because choosing which budgets matter is the judgement being scored: "There are five things I could budget. Two of them decide this design, and I am going to name the other three and then not spend time on them."

Block 3. PURPOSE: derive the byte budget rather than assert it, because an asserted number cannot survive one follow-up question.

• ASSUMED: 200 KB/s effective downlink, standing in for a congested mobile network.
• ASSUMED: a first meaningful render target of 1.5 s on that network, which is the point at which a shopper on a category page is still in flow.
• DERIVED: 1.5 s at 200 KB/s is 300 KB total on the critical path, for everything: HTML, CSS, fonts and any blocking JavaScript.
• DERIVED: allocating 40 KB HTML plus 30 KB CSS plus 30 KB of a subsetted font leaves 200 KB, which is the entire critical-path JavaScript budget, before any product images.
• The elimination: 200 KB compressed is not enough for a client-rendered page that also has to fetch its data after boot, because the data round trip lands after the JavaScript finishes transferring. So client-only rendering is out, and I have ruled it out with arithmetic instead of taste.

The error most readers make here is producing a byte number and never using it. A number that eliminates nothing should be deleted. This one killed a rendering strategy in the same breath, which is what earns it its place.

Block 4. PURPOSE: write the accessibility and device rows as testable statements, because "accessible" and "mobile" are the two words most likely to be waved at and never checked.

• "Level AA conformance for browse, filter and add-to-basket, verified by a keyboard-only pass on each flow, automated rules in continuous integration on every pull request, and one screen reader pass per new interactive component."
• "Low tier is the budget-setting device. Boot to interactive on the low tier is measured on a real device in the lab, and the number that comes out of that measurement is the budget, replacing any figure assumed here."
• "The grid reflows to a single column without horizontal scrolling at 400 percent zoom, which is a stated conformance requirement and also happens to be the same code path as the narrow viewport."

Result. Four blocks, roughly six minutes spoken. What is on the board is a functional list with states, two budgets with derivations, three eliminated options and a test method. That is a requirements phase an interviewer can grade. A feature list with "should be fast" underneath is not.

3e. Fade the scaffold

Faded example 1. Prompt: "Design the inbox view of a web email client. Most usage is on desktop, on good networks." Blocks 1 to 3 are given. Produce block 4.

• Block 1: capabilities are list messages, read a message, and compose. The interesting states are partial (the list is present while a message body is still loading) and error (a send that failed after the compose window closed).
• Block 2: the two deciding budgets are interaction latency, because this is a keyboard-heavy application used all day, and memory, because a long-lived tab accumulates.
• Block 3: DERIVED, from a target of 100 ms acknowledgement on arrow-key navigation between messages, the row change must not depend on a network request, which means the list rows carry enough data to render a header immediately.

Faded example 2. Prompt: "Design the analytics dashboard for our internal teams. Data volume is large and the users are on company laptops." Blocks 1 and 2 are given. Produce blocks 3 and 4.

• Block 1: capabilities are pick a time range, view several charts, and drill into one. Partial is the dominant state, because charts resolve at different speeds and the dashboard must be useful before all of them arrive.
• Block 2: the two deciding budgets are interaction latency during range changes, and the volume of data crossing the network per view.

3f. Check yourself

Q1. An interviewer says "assume a fast network and modern devices". Which of the five budget families still bind, and what should you say?

Q2. You write "first contentful paint under 500 ms" as a requirement. Under what conditions, and what makes this number checkable rather than decorative?

3g. When not to use this

Formal budgets are a component like any other, and they have a scale below which they cost more than they return.

Module 4. Rendering strategy

Time: 35 to 45 minutes reading, 25 to 30 minutes practice.

4a. Predict first

Four surfaces from the same company. Read the descriptions before continuing.

Six modes, defined by where and when the HTML is produced

Define these precisely before comparing them, because most disagreements about rendering are actually disagreements about definitions.

Two of these are frequently misdescribed:

• Incremental regeneration is not faster for the user. It produces exactly the same cached document as static generation. What it changes is build time and staleness, which are operational properties, not user-facing latency.
• Streaming does not reduce total time. It reorders it. The first paint moves earlier; the last byte arrives at roughly the same moment.

The comparison, with the arithmetic shown

All six numbers below come from one set of stated inputs, so you can recompute or disagree with any of them.

One more assumption, stated because it changes every result: resources transfer serially over one saturated pipe. Real browsers overlap downloads, so real numbers are better than these. The ordering between strategies survives the simplification, which is what the comparison is for.

Four conclusions fall straight out of the table, and each one eliminates something:

1. Client rendering paints content 5.9 times later than static (1355 against 230). That rules it out for any surface where the content is the product and the network is slow.
2. Client rendering reaches interactive 175 ms earlier than static (1355 against 1530). That rules out the claim that server rendering is universally faster. It is faster to content and slower to interactive, because hydration is pure added work.
3. Streaming buys 295 ms of first paint and 25 ms of content (55 against 350, and 325 against 350). That rules out streaming as a fix for slow data; it is a fix for a blank screen while data is slow.
4. Islands reach interactive 1040 ms earlier than static (490 against 1530), on identical HTML. That rules out hydration cost as an unavoidable price and moves it into Module 5, where it is a design variable.

The two numbers that actually decide

Everything above collapses into a two-by-two. Compute the two fractions from the page in front of you.

• Shared fraction: the proportion of the rendered output that is byte-identical for every user. Count regions on the page, not lines of code.
• Interactive fraction: the proportion of the rendered output that needs event handlers or client state.

The strategies drawn against a common clock

Times in ms. One 200 KB per second pipe, 30 ms round trip, low tier.

+---------------------+  +----------------------------+
| static HTML         |  | JS done 1230, hydrate 300  |
| content paints 230  |  | interactive at 1530        |
+---------------------+  +----------------------------+

+---------------------+  +----------------------------+
| islands HTML        |  | JS done 430, hydrate 60    |
| content paints 230  |  | interactive at 490         |
+---------------------+  +----------------------------+

+---------------------+  +----------------------------+
| client shell        |  | JS 1055, boot 1205         |
| paints at 55        |  | content and ready at 1355  |
+---------------------+  +----------------------------+

+---------------------+  +----------------------------+
| server HTML         |  | JS done 1350, hydrate 300  |
| content paints 350  |  | interactive at 1650        |
+---------------------+  +----------------------------+

Caption: the same page under four strategies, from the inputs in
the table above. Reading down the left column shows the content
race; reading down the right column shows the interactivity race,
and the two have different winners.

The decision table you can redraw in a minute

4d. Worked example

The prompt: "We have three surfaces on one domain: a marketing site, a product catalogue, and a logged-in account area. Pick the rendering strategy for each and defend it."

Block 1. PURPOSE: refuse the single answer, because the prompt is testing whether I treat rendering as a per-surface decision or a company-wide religion.

I say this first, out loud: "There is no one answer for the domain. These three surfaces have different shared fractions, so they get different strategies, and the interesting part is what they share underneath rather than what they share at render time."

That sentence is the whole answer to a common trap. Interviewers ask this exact question to see whether a candidate says "we would use server rendering" and stops.

The error most readers make here is picking one mode and then arguing every surface into it. The cost is invisible in the round and enormous in reality: the account area gets a server render it does not benefit from, and the marketing site gets hydration it does not need.

Block 2. PURPOSE: compute the shared fraction for each surface, because that number, not taste, selects the mode.

• Marketing: every region identical for every visitor, so the shared fraction is 1. Interactive regions are a navigation menu and a form. Islands over static.
• Catalogue: the page is a grid of products, a filter panel and a header. ASSUMED, and I say this is an assumption I want checked: prices vary by region and nothing else varies per user. If that holds, the shared fraction is roughly 1 per region rather than per user, so the page is cacheable per region and the personalised part is a small strip.
• Account: nothing is shared. Shared fraction is 0.

Block 3. PURPOSE: turn the catalogue's "almost shared" into a concrete design, because that is the only hard one and the other two are now decided.

Two candidate designs for the catalogue, and I want to eliminate one with a number rather than a preference.

• Design A: server render per request with the price already substituted. Cost: an origin render on every request, and a cache key that must include region.
• Design B: static or incremental per region, with the personalised strip fetched by the client after paint.

The eliminating number is the region count. ASSUMED at 12 regions and 50,000 products. Design B produces 12 times 50,000 documents, which is 600,000 cached objects, and that is fine for a content delivery network and impossible to build eagerly at deploy. So the answer inside Design B is incremental regeneration rather than a full static build, and I have just derived why incremental exists rather than reciting it.

The error most readers make here is choosing incremental regeneration because it sounds modern. It is a response to exactly one condition, which is a page count large enough that a full build is not viable, and that condition should be a number you say out loud.

Block 4. PURPOSE: state the cost I am accepting, because a rendering choice with no stated cost reads as a preference rather than a decision.

For each surface, one sentence of accepted cost:

• Marketing on islands: a build system that can split hydration, and the discipline to keep the island count low. If everything becomes an island, this is client rendering with extra steps.
• Catalogue on incremental regeneration: users can see a stale price for up to the staleness window. I would set that window from how often prices actually change, and if the business says prices change per minute, incremental regeneration is the wrong answer and I would move the price out of the cached document entirely.
• Account on client rendering: a slow first paint on poor networks, which I accept because the user is logged in and returning, so the JavaScript is very likely cached from a previous visit. That last clause is the actual justification, and it is worth saying, because it is why the same choice would be wrong on a first-visit surface.

Result. Three different strategies, each derived from one measurable property of the surface, each with a stated cost and one explicit assumption flagged for the interviewer to correct.

4e. Fade the scaffold

Faded example 1. Prompt: "Design the rendering strategy for a job board. Listings are public, searchable, and change hourly. Logged-in users see saved-job markers on each listing." Blocks 1 to 3 are given. Produce block 4.

• Block 1: this is one surface with two audiences, not two surfaces, so the question is how to keep one cached document serving both.
• Block 2: the shared fraction is high. The only per-user element is a marker on each card, which is a small amount of data with a large blast radius, because it appears on every item.
• Block 3: the design is a cached document for the listing content, with saved-job state fetched separately after paint and merged into the already-rendered cards.

Faded example 2. Prompt: "Our documentation site has 40,000 pages and the full build now takes 50 minutes. Writers complain they cannot see changes quickly. What do you change?" Blocks 1 and 2 are given. Produce blocks 3 and 4.

• Block 1: this is a build-time problem wearing a rendering-strategy costume. Nothing about the user-facing latency is broken.
• Block 2: DERIVED, 50 minutes over 40,000 pages is 75 ms of build time per page, which is not obviously wasteful. The problem is the total, not the per-page cost.

4f. Check yourself

Q1. A colleague says "we should use streaming server rendering, it will make the page faster". What is the one question that tells you whether they are right?

Q2. Your page is static, paints at 230 ms, and reaches interactive at 1530 ms. A stakeholder wants interactive under 700 ms. Which of the inputs from the table can you change, and which change is the largest single win?

4g. When not to use this

Each mode is a component, and each has a threshold below which it is over-engineering.

Module 5. Hydration cost and the server-client boundary

Time: 30 to 40 minutes reading, 20 to 30 minutes practice.

5a. Predict first

A page is composed of four components on the server. One of them, the like button, needs an onClick handler. The others are pure output.

What hydration actually costs

Hydration means walking the server-produced markup on the device, recreating the component tree in memory, and attaching event listeners so the markup becomes interactive. Three separate costs, and they are usually discussed as one.

The duplicated data payload, with arithmetic

This is the cost that surprises people, so derive it once.

Now compare three designs. All three display the same 40 products.

The third row is the one to internalise. Making the list interactive did not add 16 KB of behaviour; it added 16 KB of data you had already sent, expressed a second way. The fix is not compression. It is moving the boundary.

• If only the like button is interactive, pass it a product id, which is roughly 8 bytes rather than 400. Across 40 cards that is 320 bytes of serialised props instead of 16 KB, a factor of 50.
• If the card must be interactive as a whole, ask what the client actually needs. A card that only needs a title and an id to work does not need the blurb passed to it, even if the blurb is displayed, because the server already rendered the blurb into markup.

Waterfalls in server data fetching

Server components that fetch data compose beautifully and serialise accidentally. If a component awaits data, and its child awaits data that depends on the parent's result, the two requests happen in sequence.

• Serial: 4 times 80 ms is 320 ms added to time to first byte, which delays every user-visible number downstream.
• Parallel: all four start at once, so the total is the slowest, 80 ms.
• The saving is 240 ms, which is larger than the entire hydration execution term from Module 4.

+---------------------------+  +---------------------------+
| nested awaits             |  | hoisted awaits            |
| page waits 80             |  | all four start at 0       |
| then panel waits 80       |  | slowest returns at 80     |
| then list waits 80        |  | total 80 ms               |
| then item waits 80        |  |                           |
| total 320 ms              |  |                           |
+---------------------------+  +---------------------------+

Caption: the same four data calls, sequenced by component nesting
on the left and started together on the right. The 240 ms
difference is a code structure decision, not an infrastructure one.

Four ways to flatten a waterfall, ranked by what they cost you

Deduplication has its own arithmetic. If three components each fetch the same user record at 80 ms, that is 240 ms and three origin hits without deduplication, and 80 ms with one hit. The saving is exactly the same shape as request deduplication in Module 8, which is why the two modules use the same vocabulary.

5d. Worked example

The prompt: "Our product page renders on the server. Time to first byte is 520 ms and the page ships 240 KB of JavaScript. Cut both."

Block 1. PURPOSE: split the 520 ms into terms before touching anything, because two numbers with different causes are hiding inside one measurement.

I ask for one thing: the server-side timing breakdown. ASSUMED, in the absence of it, that the page does four nested data calls at roughly 80 ms and about 200 ms of rendering and framework work, which sums to 520.

That decomposition is the whole first move. 320 ms of the 520 is sequencing, which is free to fix. 200 ms is actual work, which is not. I say out loud that I would rather have the real breakdown, and that I will design against the assumption until I do.

The error most readers make here is treating time to first byte as one number and proposing a cache. A cache in front of a 520 ms render hides the waterfall from you permanently, and you will pay for it the first time the cache misses under load.

Block 2. PURPOSE: flatten the waterfall, because it is the largest term and the cheapest to remove.

Three of the four calls are independent: the product, the reviews summary and the shipping estimate. Only the fourth, related products, depends on the product's category. So the honest structure is three in parallel at 80 ms, then one dependent call at 80 ms, giving 160 ms rather than 320 ms.

That takes time to first byte from an assumed 520 to 360 ms with no infrastructure change, no cache and no new dependency. I would then ask whether the related-products call can be made independent by keying on the URL slug rather than on the fetched category, which would take it to 80 ms and the total to 280 ms.

Block 3. PURPOSE: attack the 240 KB by moving the boundary, not by splitting the bundle, because splitting defers cost and moving the boundary deletes it.

I ask which regions on the page need client behaviour. ASSUMED answer, and it is the usual one: an image gallery, an add-to-basket button, a quantity stepper and a reviews accordion. Everything else is output.

So the page is not an interactive application with a few static parts. It is a document with four widgets. That inverts the design: the default becomes server-only, and each of the four is a marked client region with a stated reason for being one.

The number I would put on the board: if the four widgets and their dependencies come to 50 KB, the page ships 50 KB instead of 240 KB. The 190 KB difference is not deferred to a later route, it is not sent.

The error most readers make here is reaching for lazy loading first. Lazy loading a 240 KB bundle still transfers 240 KB to a user who scrolls, and it adds loading states to regions that never needed them.

Block 4. PURPOSE: check the serialised payload, because I have just made four client components and each one is a boundary I can leak data through.

The reviews accordion is the risk. If it receives the full review objects as props so it can expand them, the review text ships twice: once as rendered markup inside the collapsed panel, and once as serialised props. ASSUMED, 20 reviews at 600 bytes is 12 KB of duplication.

Two fixes, and I would state both and pick: pass only the ids and fetch the bodies on expand, which costs a request and a loading state, or render the bodies on the server inside the accordion as children and let the client component control only the open state, which costs nothing and is the right answer here because the bodies are already being sent as markup.

Result. Time to first byte from 520 ms to about 280 ms, JavaScript from 240 KB to about 50 KB, and a boundary rule that stops the number climbing back. Two of the three came from structure rather than from any new technology.

5e. Fade the scaffold

Faded example 1. Prompt: "Our dashboard's first byte is 700 ms. Profiling shows six data calls, all nested, at roughly 100 ms each, plus 100 ms of render." Blocks 1 to 3 are given. Produce block 4.

• Block 1: 6 times 100 plus 100 is 700, which matches, so the model is right and the waterfall is 600 of the 700.
• Block 2: four of the six are independent; two depend on the account's tier, which is returned by the first call.
• Block 3: restructured as first call at 100 ms, then five in parallel at 100 ms, giving 200 ms plus 100 ms of render, which is 300 ms.

Faded example 2. Prompt: "We moved a list to a server-rendered boundary and the page got 40 KB bigger. Explain, and fix it." Blocks 1 and 2 are given. Produce blocks 3 and 4.

• Block 1: bytes going up after moving work to the server is the signature of duplicated data, not of extra code.
• Block 2: the list is 60 items, each item is a client component so it can handle a click, and each receives the whole item object.

5f. Check yourself

Q1. A teammate says "server components mean we ship less JavaScript, so the page will be faster". Under what condition is that false?

Q2. You have a page with a 1.2 s server data dependency for one panel, and the rest of the page is ready immediately. Give two designs and the condition that picks between them.

5g. When not to use this

Module 6. Component design: the public API surface

Time: 35 to 45 minutes reading, 25 to 35 minutes practice.

6a. Predict first

A team ships this component API to twelve consuming teams. Read the prop list before continuing.

The API surface is the only irreversible artefact

Internals can be rewritten on any Tuesday. A prop that twelve teams import cannot be removed without a coordinated migration, so the API deserves most of the round's minutes.

Controlled and uncontrolled, precisely

The distinction is about who owns the value, and confusion here produces the most common bug class in component libraries.

Three rules that resolve nearly every real case:

1. Support both, with the standard pair. value plus onChange for controlled, defaultValue for uncontrolled, and the presence of value selects the mode.
2. Fix the mode at mount and never switch. A component that starts uncontrolled and receives a value later will discard user input at an unpredictable moment. Warn loudly in development.
3. Never make onChange optional in controlled mode. A controlled component with no handler is a read-only field pretending to be editable, which reads as a bug to every user who tries it.

Compound components and inversion of control

Both exist to solve the same problem: consumers need arrangements you did not anticipate. They solve it at different costs.

The rule that stops this becoming an ideology: escalate only when a real call site forces you to. Start with props. Move to compound when a consumer needs to reorder parts. Move to a render function when the variation is in one item's content. Go headless only when the visual systems genuinely differ, because headless moves the accessibility burden to consumers who will not carry it as carefully as you would.

The layered component

+------------------------------------------+
| styled preset: tokens, spacing, variants |
+------------------------------------------+
                   |
+------------------------------------------+
| accessibility layer: roles, keys, focus  |
+------------------------------------------+
                   |
+------------------------------------------+
| behaviour core: state machine, no markup |
+------------------------------------------+

Caption: the three layers of an interactive component. Consumers
may replace the top layer. Replacing the middle layer is what
happens when a library goes headless, and it is why headless
libraries must publish the contract the middle layer enforced.

The accessibility contract, written as API

The contract has three parts, and stating them separates a component that is accessible from one that says it is.

Module 7 makes each guarantee testable. The point here is narrower: these are API decisions, not implementation details, because changing any of them changes what consumers must do.

6d. Worked example

The prompt: "Design a select component for our shared library."

Block 1. PURPOSE: get three call sites on the board before designing anything, because an API designed from imagination serves an imaginary consumer.

I ask for three, and I push for an awkward one. What I write down:

• A country picker in a settings form: single value, searchable, hundreds of options.
• A status filter on a table toolbar: single value, six options, must render a coloured dot next to each.
• An assignee picker in a comment box: multiple values, avatars, and it must submit on selection with no confirm step.

Those three already contain the design. The second forces custom option content. The third forces a different value type and a different close behaviour. If I design only for the first, I will invent booleans later to retrofit the other two.

The error most readers make here is starting from the props. Props are the output of this exercise, not the input.

Block 2. PURPOSE: decide state ownership before shape, because the ownership question changes the type signature and the type signature is the hardest thing to change later.

Two pieces of state exist and they have different owners.

• The selected value is the consumer's. It is form data, it is submitted, it survives the component. So value plus onChange, with defaultValue for the uncontrolled case.
• The open state, the search query and the active option are the component's. No consumer has a legitimate reason to own them, and exposing them invites consumers to drive the widget from outside and break the keyboard model.

I make one deliberate exception: open and onOpenChange as optional controlled props, because the table toolbar case may need to close the menu when a filter is applied elsewhere. I note that this is the one place I am widening the surface, and I say why.

Block 3. PURPOSE: pick the extension mechanism from the call sites rather than from preference, because this is where component libraries acquire their permanent complexity.

The second call site needs custom option content. Three ways to allow it, and I eliminate two:

• Add optionColor and optionIcon props: eliminated, because it solves exactly this case and the next request adds two more props. This is the boolean explosion in a different costume.
• Go fully headless: eliminated as over-correction, since the library exists so twelve teams do not each implement a keyboard model.
• A renderOption function receiving the option plus its state: chosen. It solves the general case with one prop.

The constraint that makes it safe: renderOption returns content, and the component owns the element that carries the role, the id and the selection state. The consumer cannot spread props onto the option root. That single restriction is what stops the escape hatch from becoming an accessibility hole.

The error most readers make here is handing the consumer the whole option element. It looks more flexible and it silently transfers the conformance burden to twelve teams.

Block 4. PURPOSE: name the illegal states and the versioning consequences, because that is the part nobody else in the loop will cover.

Illegal states I would make unrepresentable rather than documented:

• Multi-select and single-select are different components, not a flag, because their value types differ. This removes an entire class of casting bugs and is the single strongest decision in the design.
• Open with no options and no empty message: the empty message gets a default rather than being optional, so the state cannot be reached.
• Controlled value supplied after mounting uncontrolled: warn in development and keep the original mode, because switching discards user input.

Versioning consequences I would state up front: changing the default of closeOnSelect, tightening the type of value, or changing what the component announces are all breaking changes even though only one of them fails a build. I would ship the first with a codemod, the second as a major, and the third never without a flag.

Result. An API of roughly seven props plus a render function, two components rather than one, three named illegal states, and a written statement of what breaks consumers. That is a stronger artefact than a twelve-prop component that covers more cases.

6e. Fade the scaffold

Faded example 1. Prompt: "Design a modal dialog for the shared library." Blocks 1 to 3 are given. Produce block 4.

• Block 1: three call sites are a confirm dialog with two buttons, a form dialog that must not close on outside click while dirty, and a full-screen media viewer on small screens.
• Block 2: open and onOpenChange are the consumer's, because opening is caused by consumer events. Focus location and scroll locking are the component's, and no consumer should own them.
• Block 3: compound parts (a root, a trigger, a content region, a title and a description) rather than a title prop, because the form case needs arbitrary content and the media case needs no title chrome at all.

Faded example 2. Prompt: "Design a toast or notification component." Blocks 1 and 2 are given. Produce blocks 3 and 4.

• Block 1: call sites are a success confirmation after saving, an error with a retry action, and an upload progress toast that updates in place over 30 seconds.
• Block 2: the queue is the component's, since two teams firing toasts must not each manage stacking. The content is the consumer's. Dismissal timing is shared, which is the tension in this design.

6f. Check yourself

Q1. A consumer asks you to add a hideLabel boolean to your input component. What do you ask, and what are the two possible right answers?

Q2. Your component has six boolean props. What is the number you would put on the board to argue for a redesign, and what would you replace them with?

6g. When not to use this

Module 7. Accessibility as engineering

Time: 40 to 50 minutes reading, 25 to 35 minutes practice.

7a. Predict first

A team ships a "custom dropdown". Here is what it is made of, described in plain terms.

Conformance is a claim, so state it precisely

The Web Content Accessibility Guidelines define success criteria at three levels: A, AA and AAA. Level AA is the level normally written into policy and procurement, so it is the default target to state in a round. The specification is published by the W3C at w3.org/TR/WCAG22.

Three properties of a conformance claim that candidates routinely get wrong:

• Conformance applies to whole pages, not to components. A component cannot be conformant by itself, because criteria such as focus order and page structure are properties of the page it sits in. A component can be built so that a conformant page is achievable, which is what a component library actually ships.
• Conformance applies to complete processes. If checkout has five steps and step four is unusable, the process fails even if four pages pass.
• Anything on the page can break it. A third-party widget that traps focus fails the page it is on, regardless of the quality of your own code.

The four principles are worth keeping in your head as a triage ladder rather than as a recitation, because they sort bugs by who is affected and what the fix costs.

The authoring pattern, per interactive component

Each interactive widget has an expected structure, key set and focus rule. Consumers of your component and users of your product both rely on the expectation. This table is the working set for an interview.

Focus management, the three mechanisms

Mechanism one: the trap. A modal dialog must contain focus, because a user who tabs out lands on content that is visually behind an overlay. Trapping is three parts: move focus in on open, cycle at the boundaries, and make the rest of the page inert so that assistive technology cannot reach it either. Hiding content visually is not enough, because a screen reader reads the accessibility tree rather than the pixels.

Mechanism two: restoration. On close, focus returns to whatever opened the dialog. The case everyone forgets: the trigger no longer exists, because the dialog deleted the row it lived in. Falling back to the document body drops the user at the top of the page and loses their position entirely, so the fallback should be the nearest stable ancestor, such as the list that contained the deleted row.

Mechanism three: roving tabindex. In a composite widget the whole widget is one tab stop and arrow keys move inside it. The arithmetic makes the case:

The alternative to roving is an active-descendant reference, where focus stays on a container and the container names which child is currently active. Choose between them on one question.

+----------------------+
| trigger button       |
| focus starts here    |
+----------------------+
           |
           v
+----------------------+
| dialog opens         |
| focus moves inside   |
| rest of page inert   |
+----------------------+
           |
     +-----+-----+
     |           |
     v           v
+-----------+ +--------------------+
| Tab       | | Escape closes      |
| cycles    | | focus returns to   |
| inside    | | the trigger        |
+-----------+ +--------------------+
                       |
                       v
        +-----------------------------+
        | trigger no longer exists    |
        | focus goes to the list that |
        | contained it, not the body  |
        +-----------------------------+

Caption: the focus lifecycle of a modal dialog, including the
case that is usually missed, where the element that opened the
dialog was removed by the action taken inside it.

Accessible names, and the icon-button trap

Every interactive element needs a name that assistive technology can read. The sources are consulted in a precedence order, and knowing the order explains most naming bugs.

1. An explicit labelled-by reference to other elements on the page.
2. An explicit label attribute carrying a string.
3. A native association, such as a form label bound to its control.
4. The element's own text content, for elements that take their name from content, such as buttons and links.
5. A title attribute, which is a last resort and is not exposed to all users.

Two consequences worth stating out loud in a round:

• A labelled-by reference overrides visible text. So an icon button with visible text plus a stale label attribute announces the stale string, and no visual review will ever catch it.
• An icon button has no text content, so it has no name at all unless you provide one. This is the single most common naming failure, and it is invisible in every screenshot.

Live regions, used sparingly

A live region announces content changes without moving focus. Three rules cover nearly all correct use.

• The region must exist in the document before the text changes. Inserting a live region and its content at the same moment frequently announces nothing, because there was no region to observe.
• Polite is the default. Assertive interrupts whatever is being read, so reserve it for errors and events the user must handle now.
• Announce a summary, not a payload. "12 results" is useful. Marking a whole result list as live means every keystroke re-announces the entire list, which is worse than silence because the user cannot escape it.

Two adjacent behaviours belong here because they are functional requirements rather than polish:

• Reduced motion. When the user has asked the operating system for reduced motion, shorten or remove transitions, disable parallax and stop anything that moves without being asked. The correct response is not "delete all animation": a shortened transition still communicates that something changed.
• Error announcement in forms. Bind the error text to the field so it is read when the field is reached, keep it present rather than transient, and never convey the error state with colour alone. On submit, move focus to a summary that lists the failures and links to each field, because a user who cannot see the page has no other way to find out how many problems exist.

Testing: sort by what a machine can decide

Percentages of "issues caught by automation" circulate widely and depend entirely on the sample. Sorting by decidability is more useful and cannot go out of date.

The practical consequence is the acceptance test to state in a round: automated rules gate every pull request and catch the first tier only; a keyboard-only pass is required for every new interactive flow; one screen reader pass is required for every new interactive component; and a zoom and reflow check is required for every new layout.

The five-minute manual pass, which is what to describe when asked how you would verify a design:

1. Put the mouse away. Tab through the whole flow and complete it.
2. At every stop, check that the focus indicator is visible against the actual background.
3. In every composite widget, use the arrow keys and Escape, not just Tab.
4. Zoom to 400 percent and check that content reflows without a horizontal scrollbar.
5. Turn on a screen reader and complete one task, listening specifically at the moments where state changes.

7d. Worked example

The prompt: "Make our custom combobox conformant. It is the one from the pre-question."

Block 1. PURPOSE: define the interaction model in plain language before touching any attribute, because the attributes describe a model that must already exist.

I write the model as sentences, not as markup: focus lives in the text input at all times; typing filters; Down opens the list and moves the active option; Up moves back; Enter selects the active option and closes; Escape closes without selecting, and a second Escape clears the input; clicking outside closes; the input's value is not overwritten by the active option while browsing.

That last clause is the one people miss, and it is a design decision rather than an accessibility one: browsing with arrows must not destroy what the user typed.

The error most readers make here is opening the accessibility work by adding roles. Roles applied to a widget with no interaction model produce something that announces itself correctly and still does not work.

Block 2. PURPOSE: map the model onto roles, relationships and state, because that is what makes the working widget legible to assistive technology.

Four mappings, each traceable to a sentence from block 1:

• The input is a combobox that controls the list, and it carries an expanded state. That comes from "Down opens the list".
• The list is a listbox, and each child is an option with a selected state. That comes from "Enter selects the active option".
• The input names its active option by reference, using active descendant rather than moving focus. That comes from "focus lives in the input at all times".
• A status region reports the result count when filtering changes it. That comes from "typing filters", which is a change a sighted user sees and a screen reader user otherwise does not.

Block 3. PURPOSE: handle the focus and announcement edge cases, because this is where a widget that passes a demo fails in production.

• Filtering to zero results: the active descendant reference now points at an id that no longer exists. Clear the reference and announce "no results" through the status region, rather than leaving a dangling reference which silently announces nothing.
• Closing on selection: focus stays on the input, and the value updates. Announcing the selection is handled by the input's own value change, so a second announcement through the status region would say everything twice.
• The list scrolls: the active option must be scrolled into view as arrows move, or a sighted keyboard user loses their position even though the widget is technically correct.
• Announcement volume: I announce the count on a debounce rather than on every keystroke, because a user typing six characters should not hear six counts.

The error most readers make here is announcing more, on the assumption that more speech is more accessible. Verbosity is its own failure: an interface that narrates everything is harder to use than one that narrates only what changed.

Block 4. PURPOSE: write the tests, because an accessibility claim with no test is a promise that decays with the next refactor.

Four tests, one per tier plus the manual gate:

• Automated rules in continuous integration, asserting the machine-decidable tier on a rendered page containing the component in both open and closed states. The closed state alone would miss every relationship.
• Unit or integration tests asserting the key model directly: Down opens, arrows move the active reference, Escape closes, Enter selects, and the input value survives browsing. These are ordinary tests, and they are the ones that catch the regression a year later.
• An assertion that the status region exists before the first filter, since a region created at announcement time frequently announces nothing.
• A manual gate in the pull request template: one keyboard-only pass and one screen reader pass, recorded, for any change to this component.

Result. The widget now works before it announces, announces what it does, and has tests that fail if either half breaks. Note the order: model, then semantics, then edge cases, then tests. Reversing the first two is the most common way this work is done badly.

7e. Fade the scaffold

Faded example 1. Prompt: "Our data table has sortable column headers built as clickable header cells. Make it conformant." Blocks 1 to 3 are given. Produce block 4.

• Block 1: the model is that each sortable header is a control, activating it cycles ascending, descending and possibly none, and the current sort is a property of the column rather than of the page.
• Block 2: the header cell carries the sort state, and the control inside it is a real button so that Enter and Space work without re-implementation.
• Block 3: edge cases are the initial unsorted state, which must be distinguishable from ascending; and the announcement on sort, which must say what happened without reading the whole table.

Faded example 2. Prompt: "Design the accessibility contract for a drag-to-reorder list." Blocks 1 and 2 are given. Produce blocks 3 and 4.

• Block 1: dragging is a pointer gesture with no keyboard equivalent by default, so an alternative path is not an enhancement, it is the requirement.
• Block 2: the model is that each item can be picked up, moved and dropped, and every one of those has a keyboard equivalent: a key to pick up, arrows to move, a key to drop, Escape to cancel and restore.

7f. Check yourself

Q1. A designer asks you to remove focus outlines because they look bad on the brand's buttons. What do you say, and what do you actually ship?

Q2. Your automated accessibility rules pass on every page. What can you claim, and what can you not?

7g. When not to use this

Module 8. State, split three ways

Time: 35 to 45 minutes reading, 25 to 35 minutes practice.

8a. Predict first

A team's global client store has six slices. Read them before continuing.

The three kinds, and the test that sorts them

The sorting test, three questions in order. The first that answers yes decides.

1. Does anything outside this tab own the truth? Then it is server cache state, and it needs a key and a staleness rule.
2. Would two distant components disagree if this were local? Then it is shared client state.
3. Otherwise it is local, and it should live in the component that owns the interaction.

There is a fourth question worth asking before all of them, because it removes work rather than assigning it: should this survive a reload, be shareable as a link, and respond to the back button? If yes, it belongs in the URL, and the URL then becomes the input to the server-cache key rather than a second copy of it.

Server cache state, mechanically

This is the part that is easy to use through a library and hard to derive from scratch, so it is worth deriving once. Five mechanisms, each with arithmetic.

Cache keys

The key is the complete input to the query. Anything that changes the response and is not in the key is a bug waiting for a user to find.

• A list query taking a search term, a sort, a page number, a page size and a facet set has five key components. Omitting the facet set means two different filtered results share one entry, and the second reader sees the first reader's data.
• Keys must be normalised before comparison: object keys sorted, strings trimmed, numbers not compared to their string forms. Otherwise two logically identical requests miss the cache, and the hit rate quietly halves.
• Do not put in the key anything that does not change the response. Adding a timestamp or a render count to a key produces a cache with a hit rate of zero, which is a very expensive way to disable a feature you are still paying to maintain.

Deduplication

Multiple components asking for the same key within a short window should produce one request.

Without deduplication: 12 requests over 6 connections is 2 rounds, so about 120 ms and 12 origin hits. With deduplication: one request, 60 ms, one origin hit. The saving is small on latency and large on origin load, which is the honest way to argue for it.

Staleness and revalidation

Two separate timers, and conflating them is the usual bug.

Derive the staleness window from the data, not from a habit. If a value changes at most once an hour, a five-minute window bounds staleness at five minutes, which is well inside the change rate.

• ASSUMED: a 12-minute session in which 20 components mount and each would otherwise fetch on mount.
• Without a staleness window: 20 requests.
• With a five-minute window: at most 3 fetch events in 12 minutes, since 12 divided by 5 rounds up to 3.
• That is a factor of roughly 7 in origin load, bought with a bounded 5 minutes of staleness.

Revalidation triggers each carry a cost, so choose them per query rather than globally:

Normalisation

The same entity appearing in several query results is the source of the classic bug: liking a post updates it in the feed and not in the profile list, because they are two independent cached responses.

The threshold worth stating: if you can name the affected keys after a mutation in one line, per-query invalidation is sufficient. When that list becomes long enough that people get it wrong, normalisation starts to pay.

Optimistic updates and rollback

Three steps, in order, and the third is the one that gets skipped.

1. Snapshot the current cached value for every key you are about to change.
2. Apply the predicted result immediately, so the interface acknowledges within the 100 ms budget from Module 3.
3. Reconcile: on success, replace the prediction with the server's answer, because the server may have changed something you did not predict. On failure, restore the snapshot and tell the user.

Optimistic updates are only safe under three conditions, and saying them is what separates a considered answer from a habit:

• The result is predictable locally. A like toggles; a document merge does not.
• Failure is rare, so the interface is not routinely lying.
• Failure is reversible without loss. Rolling back a like is fine. Rolling back "message sent" after the user closed the composer is not.

The three stores, drawn

+-------------------+   +--------------------+  +-------------+
| URL               |   | server cache       |  | local state |
| query, filters,   |-->| key = URL inputs   |  | open, hover |
| page, selected id |   | staleness window   |  | draft text  |
+-------------------+   +--------------------+  +-------------+
        |                     |         |
        v                     v         v
+-------------------+   +--------------------+
| shared client     |   | mutation           |
| theme, session,   |   | invalidates named  |
| feature flags     |   | keys, then refetch  |
+-------------------+   +--------------------+

Caption: the URL feeds the server cache key, so there is one
source of truth for what is being viewed. Mutations invalidate
keys rather than writing into the cache by hand, and local state
never crosses into either store.

8d. Worked example

The prompt: "Design the state for a filterable, paginated table of orders, where a row can be marked as refunded from a detail panel."

Block 1. PURPOSE: sort every piece of state before designing any of it, because the sorting decides the architecture and takes ninety seconds.

Running the test on each piece:

The move worth noticing is the fourth row. Panel-open state is not stored at all, because it is a function of the URL. Deleting state is the cheapest correctness improvement available, and it is the move an answer reaches for last, because adding a store feels like design and removing one does not.

The error most readers make here is starting with the store and asking what to put in it. Start with the state and ask where each piece belongs, and the store ends up small.

Block 2. PURPOSE: design the key before the fetching, because the key is what makes every later behaviour correct or wrong.

The key for the list is the tuple of search text, status, date range, sort, page and page size. Six components, all from the URL. Normalisation rules I state explicitly: trim the search text, treat empty string and absent as the same value so they do not create two entries, and sort the status array so that two orderings of the same filter share one entry.

The key for the detail is just the order id, which means the detail is shared between the table and any other place that shows one order, at no extra cost.

Block 3. PURPOSE: choose the staleness and revalidation policy per query, because a global policy is always wrong for at least one of them.

• The list: orders arrive continuously, but a table being read does not need second-level freshness. ASSUMED staleness window of 30 seconds, revalidate on focus, no interval. Justification: a user returning to the tab wants current data, and a user staring at the table is not making decisions that turn on a 30 second difference.
• The detail: staleness of zero while the panel is open, because the user is about to act on it, and acting on a stale refund state is exactly the failure this design must avoid.

I say the asymmetry out loud, because it is the decision: reading is cheap and stale is fine, acting is expensive and stale is not.

The error most readers make here is one global staleness setting. It is either too aggressive for the list, so the origin carries pointless load, or too relaxed for the detail, so a refund is issued against stale state.

Block 4. PURPOSE: design the mutation, because refunding is where correctness, optimism and invalidation all meet.

Refund is a case where I would not be optimistic, and saying why is the point: the result is not locally predictable (a refund can be declined by the payment provider), and the failure is not cheap to reverse in the user's mind, because showing "refunded" and then withdrawing it is worse than a two second wait.

So: a pending state on the button, a disabled control to prevent double submission, an idempotency key on the request so a retry cannot double-refund, and on success, invalidate two keys, the detail for that order and the list key. I would invalidate rather than write the new value into the cache by hand, because the server may have changed the order's status, its timeline and its totals, and hand-writing one field leaves the other two stale.

Result. The URL owns what is being viewed, the cache owns what the server said with a per-query staleness rule, local state owns two booleans, and the mutation invalidates rather than patches. Nothing in this design is a global store, which is the outcome the sorting test produces most of the time.

8e. Fade the scaffold

Faded example 1. Prompt: "Design the state for a chat window: a message list, a composer, and a read receipt sent when messages become visible." Blocks 1 to 3 are given. Produce block 4.

• Block 1: the conversation id is in the URL; the message list is server cache state with a push channel updating it; the composer draft is local but must survive a reload; scroll position is local and must not be stored globally.
• Block 2: the key is the conversation id plus a cursor, and the cache holds pages that must merge rather than replace, since a new page must not evict the previous one.
• Block 3: staleness is effectively infinite while the push channel is connected, and collapses to zero on reconnect, because the channel is the freshness mechanism and the cache is only correct while it is connected.

Faded example 2. Prompt: "Our app keeps everything in one global store and the team says it is slow and hard to reason about. What do you change first?" Blocks 1 and 2 are given. Produce blocks 3 and 4.

• Block 1: two complaints, two different causes. "Slow" is usually re-render scope. "Hard to reason about" is usually that server data lives in a client store with hand-written fetching.
• Block 2: I would measure before moving anything, and the measurement is which components re-render on an unrelated update, since a single store with a coarse subscription re-renders everything.

8f. Check yourself

Q1. A colleague proposes caching every query for 24 hours to reduce origin load. What do you ask, and what is the risk?

Q2. You have a list query cached under key A and a detail query under key B. A mutation changes the entity. Which do you invalidate, and what goes wrong if you patch instead?

8g. When not to use this

Module 9. Data fetching and caching: HTTP semantics to browser storage

Time: 35 to 45 minutes reading, 20 to 30 minutes practice.

9a. Predict first

Three responses from the same application. Read the headers before continuing.

The cache chain, in order

A request passes through several caches, and the order decides which header matters where.

+-----------+   +--------------+   +---------------+
| memory    |-->| service      |-->| HTTP cache    |
| cache in  |   | worker if    |   | on disk       |
| this tab  |   | registered   |   | shared tabs   |
+-----------+   +--------------+   +---------------+
                                          |
                                          v
                +--------------+   +---------------+
                | origin       |<--| CDN edge      |
                | server       |   | shared by all |
                +--------------+   +---------------+

Caption: the path of one request. The service worker sits in
front of the HTTP cache, so its code can override every header
below it, which is why a bad service worker is the stickiest
failure in frontend delivery.

Two consequences worth stating in a round:

• A service worker overrides your headers. If a worker serves from its own store, no-store on the response does not save you. The worker is code, and code beats configuration.
• The CDN is shared and the browser cache is not. Anything marked as cacheable by a shared cache must be identical for every user who could receive it, which is the rule row three of the pre-question broke.

Response directives, and the bug each one causes when confused

The rules are specified in RFC 9111, the HTTP caching specification, at rfc-editor.org/rfc/rfc9111.

Validators, and what a 304 still costs

A validator lets a cache ask "has this changed?" and receive a small answer instead of the whole body. An entity tag is an opaque token for a version; a last-modified date is a coarser fallback with one-second resolution.

A 304 saves bytes. It does not save the round trip, and on a page with many assets the round trips are the cost.

• Revalidating all 40: 40 divided by 6 rounds up to 7 batches, so 7 times 60 ms is 420 ms of pure "nothing has changed".
• With content hashes and immutable: 0 ms, because no request is made at all.

That 420 ms is the entire argument for content hashing, and it is derivable in ten seconds on a whiteboard.

Content hashing, and the two-tier rule

Every static delivery strategy reduces to two tiers.

The consequence people miss: with content hashing you almost never purge. Purging exists for the pointer document and for API responses. If your deploy process includes purging your JavaScript, either you are not content hashing or you are purging out of superstition, and both are worth saying out loud.

One real hazard to name: a deploy that removes old asset files breaks any user still holding the old pointer document, because their HTML references URLs that no longer exist. Keep the previous few builds' assets available, and the length of that window is a number you should choose rather than inherit.

CDN cache keys, and why Vary is dangerous

The cache key is what the CDN uses to decide whether two requests are the same request. By default it is roughly the method, the host and the path with its query string. Anything else you add multiplies the number of stored variants.

The hit rate model is simple enough to do out loud. For a URL receiving N requests per freshness window, with K distinct key variants, roughly K of those requests miss and the rest hit, so the hit rate is about 1 minus K over N.

That is the whole argument against varying on a user agent string: the key space is unbounded, so the cache stops being a cache while continuing to cost money and add a hop. Varying on a small, normalised set is fine, and the discipline is to normalise at the edge into a few classes before the key is computed.

Purging strategies, compared:

Prefer soft purge. A hard purge of a popular key sends every waiting request to the origin at the same instant, which is the cache stampede described in the failure library on the hub.

Browser storage tiers

Six places to put bytes on a device, and choosing wrongly is a common source of both jank and data loss.

Two derivations that settle common arguments:

Cookies are an upload tax. Assume 4 KB of cookies on the origin, 60 requests during a page load, and an uplink of 1 Mbit/s, which is 125 KB/s. Then 4 KB times 60 is 240 KB uploaded, and 240 divided by 125 is about 1.9 seconds of uplink time spread across the load, on a connection whose downlink you were already fighting for. That is the argument for keeping cookies to a session identifier and serving static assets from a cookie-free origin.

localStorage is a main-thread cost. It is synchronous, so a read blocks everything, including rendering the frame that is currently in flight. Reading a 2 MB JSON blob from it during startup is both a synchronous disk read and a parse, on the thread that is trying to paint. IndexedDB does the same work off the main thread, which is the whole reason to prefer it for anything larger than a preference.

9d. Worked example

The prompt: "Write the caching plan for our application: the HTML entry, the hashed bundles, user avatars, and a list endpoint."

Block 1. PURPOSE: classify each resource by who it varies for, because that single property decides every header that follows.

Avatars are the interesting row and the one people get wrong in both directions. The image of user 12 is the same bytes for everyone who views it, so it is shared-cacheable. What is private is which avatars a given user sees, and that is a property of the page, not of the image.

The error most readers make here is classifying by "is it user data" rather than by "does the response body vary by requester". Those are different questions and only the second one decides the headers.

Block 2. PURPOSE: assign headers, and justify each number rather than copying a convention.

• HTML entry: no-cache. Every visit costs one round trip, assumed 60 ms, and usually returns a 304. I accept that 60 ms because it is what guarantees a user gets the current build immediately after a deploy, and because it is the pointer for everything else.
• Hashed bundles: max-age=31536000, immutable, which is 365 times 86400 seconds. The immutable part is what removes revalidation even on an explicit reload, and it is what turns the 420 ms of 304s calculated earlier into zero.
• Avatars with a version in the path: max-age=31536000, immutable, public. Public is correct here and would be a leak on the list endpoint, and being able to say why is the point.
• List endpoint: private, no-store if the data is sensitive, or private, max-age=30 if a 30 second window is acceptable and I can name what a user could do wrong with 30 second old data. I would ask, not assume.

Block 3. PURPOSE: design the deploy behaviour, because a caching plan that has not thought about deploys is half a plan.

• Assets from the previous builds stay available for a stated window. ASSUMED at seven days, on the reasoning that a tab left open over a weekend plus a day of slack is the realistic worst case, and the storage cost of a few extra builds is negligible next to a broken session.
• The entry document is not purged, because no-cache already revalidates it. Nothing else needs purging, since everything else is content addressed.
• A running client that fails to load a hashed chunk after a deploy needs a recovery path, because that failure is real if the window expires: detect the load failure and reload the page once, which fetches a fresh entry document and therefore fresh URLs.

The error most readers make here is stopping at headers. The deploy interaction is where caching plans fail in production, and it is invisible in a header table.

Block 4. PURPOSE: decide the storage tiers, because the same plan has to say where anything kept on the device lives.

• Session identifier in a cookie, marked as HTTP-only and same-site, and nothing else in cookies. Justification is the 240 KB upload derivation: every extra kilobyte in a cookie is paid on every request.
• User preferences such as theme in localStorage, because they are tiny, needed synchronously before first paint to avoid a flash, and losing them is harmless.
• Anything larger, such as a cached list for offline reading, in IndexedDB, because the read must not block the main thread.
• No copy of the API responses in Cache Storage unless there is a service worker with a stated offline requirement, because a second cache with its own lifetime is a consistency problem I would rather not own.

Result. Four resource classes, four header sets each justified by a property of the resource, a deploy window with a stated reason, a recovery path for the failure that window does not cover, and a storage assignment derived from two costs rather than from habit.

9e. Fade the scaffold

Faded example 1. Prompt: "Our CDN hit rate is 40 percent and we do not know why." Blocks 1 to 3 are given. Produce block 4.

• Block 1: a low hit rate is a key problem, a freshness problem or a traffic problem, and they are distinguishable. Key problems show as many variants of one URL; freshness problems show as short lifetimes; traffic problems show as low request counts per URL, where nothing is wrong at all.
• Block 2: the request logs show one URL with thousands of key variants, which points at a key that includes something it should not.
• Block 3: the responses carry a Vary on a header that differs per browser build, so the key space is effectively unbounded and the hit-rate model gives approximately zero for that URL.

Faded example 2. Prompt: "A user reports seeing an old version of the application even after refreshing. Diagnose." Blocks 1 and 2 are given. Produce blocks 3 and 4.

• Block 1: refreshing normally revalidates the entry document, so if a refresh does not fix it, something is serving the old entry document or overriding the entry document entirely.
• Block 2: the candidates are an entry document with a long max-age, an immutable directive on a non-hashed URL, a CDN that has cached the entry document with a long shared lifetime, or a service worker serving the application shell from its own store.

9f. Check yourself

Q1. Explain the difference between no-cache and no-store to a colleague, and say when each is right.

Q2. You add a Vary: Accept-Language to responses for a site with 12 locales. What happens to the CDN, and what should you do instead if the hit rate matters?

9g. When not to use this

Module 10. Network and real-time

Time: 32 to 42 minutes reading, 20 to 30 minutes practice.

Real-time answers fail in a recognisable way. The transport is named in the first sentence, and everything that decides whether the screen actually works is skipped. Direction, message rate and what the interface does while the connection is gone are what choose a transport. The transport itself decides very little.

10a. Predict first

Read this specification and commit to an answer before continuing.

Question. Name the number that eliminates this design before you reach the transport at all, and say what breaks first on the device.

Four transports, compared on what actually differs

The primary sources, so you can check any of this rather than take it from a table: WebSocket is RFC 6455, published December 2011, which is also where the ping and pong control frames are defined. Server-sent events are specified in the HTML standard, which defines EventSource, the reconnection behaviour, the retry field and the Last-Event-ID request header. WebTransport is a W3C Candidate Recommendation Snapshot dated 30 July 2026, which describes multiple streams and unreliable datagrams.

The row that changes most answers is the second one. Server-sent events give you the two things teams most often get wrong when they hand-roll them, automatic reconnection and a resume point, and they give them away for free. A WebSocket gives you neither and is chosen anyway, because "live" and "bidirectional" have become the same word.

The transport decision, drawn

+------------------------------------------+
| Does the client send messages up too,    |
| on the same channel and at message rate? |
+------+---------------------------+-------+
       | no                        | yes
       v                           v
+----------------+     +------------------------+
| updates faster |     | WebSocket. You now own |
| than one every |     | reconnect, heartbeat,  |
| ten seconds?   |     | resume and shedding    |
+---+--------+---+     +------------------------+
    | yes    | no
    v        v
+---------+ +------------------+
| server- | | poll on a timer  |
| sent    | | and stop calling |
| events  | | it real time     |
+---------+ +------------------+

Caption: the transport routing question, top to bottom. The first
fork is direction, the second is rate. Long polling is where the
left leaf goes when server-sent events cannot be used at all, and
WebTransport is the right leaf when you need unreliable datagrams
and can afford to carry a fallback for clients without it.

Two clarifications the diagram deliberately leaves out. A client that sends one message on open, or one message per user action, is not sending "at message rate", so it stays on the left branch and posts its writes over ordinary HTTP. And a screen with several live topics does not need several connections: multiplex topics over one stream and give each topic its own sequence.

Reconnection: backoff, jitter, and why jitter is the load-bearing half

Backoff without jitter is a synchronised retry. Every client that dropped at the same instant comes back at the same instant, which is how a recovering server is knocked over by its own users.

The arithmetic that justifies the cap, with the inputs stated. ASSUME 200,000 connected clients, the same population the market data problem in the interleaved set uses, and ASSUME a restart drops all of them at once.

Retrying on a fixed one second delay puts 200,000 attempts into one second. Spreading the same attempts uniformly across a 30 second cap gives about 6,700 a second, a factor of 30 lower, and the price is that the unluckiest client waits 30 seconds. Pick the cap from what a user will tolerate staring at a stale screen, then check the arrival rate it implies.

Not every disconnect deserves a retry, and treating them alike is a real bug.

One interface rule worth stating out loud, because it is cheap and almost always missing: do not show a "reconnecting" banner on the first failure. A one second blip that recovers on attempt one should be invisible. Show the banner from the second failed attempt, and show a stale-data timestamp rather than a spinner, because a spinner claims progress you cannot promise.

Heartbeats and liveness

A closed connection is easy. A dead connection that nobody has closed is the problem, and it is common: a phone that loses radio sends no close frame, and an intermediary can drop an idle connection without telling either end. The socket stays open in your code and delivers nothing forever.

So liveness is an application concern, with two numbers.

• Send interval. ASSUMED at 20 s here. Choose it below the shortest idle timeout on your own path, measured rather than inherited, because that timeout belongs to whatever proxies and gateways your traffic actually crosses.
• Liveness deadline. Two missed beats plus a margin, so about 45 s at a 20 s interval. Below two missed beats you will tear down healthy connections on ordinary jitter.

The cost is a wakeup, not bytes. At a 20 s interval a client sends 3 beats a minute, so 180 an hour. At 5 s it sends 720 an hour, four times the radio wakeups to detect death four times sooner. On a phone that is a battery decision, so state the trade rather than picking 5 seconds because it feels responsive.

Two details that separate a designed answer from a remembered one. First, heartbeats must run in both directions: a server that only listens cannot reclaim the socket of a client that vanished, and connection slots are the resource that runs out. Second, server-sent events reconnect automatically but do not detect a silently dead connection, so a stream that has delivered nothing past your deadline should be closed and reopened by your own code.

Ordering and deduplication on the client

A single connection preserves the order of what it carries. That guarantee ends at the edges, and every edge is where the bugs live.

Three rules that make the receive path boring, which is the goal.

• Detect gaps, do not paper over them. If an arriving sequence is greater than the last applied plus one, messages were missed. Refetch the snapshot and resubscribe. Applying the message anyway leaves a client that is silently wrong, which is worse than a visible reload.
• Deduplicate against a bounded set. Keep seen message ids in a fixed-size ring, sized from the rate and the resume window. At an assumed 60 chat messages an hour and a 30 minute session, 30 ids covers the session, so a 200 entry ring is generous and cannot grow. An unbounded seen-set is a memory leak that only appears in long sessions, which is exactly where nobody tests.
• Prefer idempotent application. "Set price to 41.20 at version 9" survives a duplicate. "Increment unread by one" does not. Where the payload is a delta by nature, carry a version and ignore anything at or below the version already applied.

The receive path, drawn

+----------+   +-----------+   +-----------+   +-----------+
| socket   |-->| drop ids  |-->| sequence  |-->| coalesce  |
| message  |   | already   |   | check,    |   | by key    |
| arrives  |   | seen      |   | gap alarm |   | into a    |
|          |   |           |   |           |   | buffer    |
+----------+   +-----------+   +-----------+   +-----+-----+
                                                     |
                                     once per frame  v
                                          +---------------------+
                                          | apply to state and  |
                                          | render visible rows |
                                          +---------------------+

Caption: one message from the socket to the screen. Deduplication
comes before the sequence check so a replayed message after a
resume does not raise a false gap alarm. Everything to the left of
the buffer runs per message; everything to the right runs at most
once per frame, which is what stops the message rate from setting
the render rate.

Coalescing, batching, and the difference

Coalescing drops superseded messages. Batching keeps all of them and applies them together. Choosing the wrong one either loses data or fails to reduce anything.

The saving is worth computing rather than asserting. From the predict-first numbers, 5,000 messages a second coalesced per frame at 60 frames a second is at most 60 state writes a second instead of 5,000, which is about 83 times fewer renders. Coalescing by key also collapses the 40 visible instruments to at most 40 changed values a frame, so the render is bounded by what is on screen rather than by what the market is doing.

One frame is the upper bound on flush rate, not the right answer everywhere. A number a person reads rather than watches move can flush on a longer interval, say once per 100 ms, which is another factor of six and is often more legible because the digits stop flickering. Pick the interval from what the value is for, then say which one you picked and why.

Backpressure when the server outruns the render loop

Backpressure means deciding, deliberately, what happens when input arrives faster than you can consume it. Doing nothing is also a decision, and the thing it decides is that the buffer grows until the tab dies.

Four levers, cheapest first.

1. Filter at the source. Subscribe to the visible set and resubscribe on scroll. In the predict-first problem this is 40 of 500 instruments, so it removes 92 percent of the traffic and the bytes with it. It is the cheapest lever and the one most often skipped, because it needs a server that accepts a subscription list.
2. Conflate on the server. Send at most one update per key per interval, say one per 100 ms. This is the only lever that saves the bytes as well as the work, and from the arithmetic above the bytes were the binding constraint, so on that problem it is not optional.
3. Coalesce per frame on the client. No server change needed, so it is available immediately. It saves renders but still pays the download, the parse and the deduplication for every message.
4. Shed. If the pending buffer exceeds a stated bound, stop applying, refetch a snapshot and resubscribe. Shedding is what keeps a slow client correct rather than merely behind.

The measurement that tells you which lever you need is the depth of the pending buffer sampled over a window. A depth that returns to zero every frame is healthy. A depth that trends upward over five seconds means the client is losing, and long task count and interaction latency will confirm it a moment later. If parsing is the cost rather than rendering, move the socket and the parse into a worker and post only the coalesced result to the main thread.

10d. Worked example

The prompt: "Design the live-updating part of an order tracking screen: the courier's position on a map, the order state, and a chat thread with the courier."

Block 1. PURPOSE: separate the streams by direction and by what a lost message costs, because those two properties decide everything downstream.

The error most readers make here is picking one transport because the three streams share one screen. They share a screen and nothing else. The position stream can lose messages all day, and the chat send path cannot lose one ever, which is a durability requirement rather than a transport requirement.

Block 2. PURPOSE: choose transports, and state what each choice costs rather than only what it buys.

• All three receive paths ride one server-sent events stream carrying three topics, each with its own sequence. Reconnection and the resume point are already in the client, and the direction is one way. Cost: text only, so any binary payload is encoded, and one connection per tab.
• Chat sends are ordinary HTTP requests carrying a client-generated idempotency key, not socket frames. A send has to survive the tab closing, and a socket cannot promise that. Cost: a request per message instead of a frame, which at this rate is nothing.
• What this rejects, out loud: a WebSocket for everything. It buys bidirectionality that only chat wants, and chat is better served by a request that can be queued, retried and deduplicated by a key the server already needs.

Block 3. PURPOSE: design the receive path, because ordering and duplication are settled here or not at all.

• Each topic carries a monotonic sequence. On reconnect the client resumes from the last applied sequence per topic. A gap triggers a snapshot refetch for that topic only, not for the screen.
• Deduplication by message id against a 200 entry ring per topic, sized from an assumed 60 chat messages an hour against a 30 minute session, which is about 30 ids.
• Position messages coalesce by key and flush once per frame, so a burst after a tunnel paints one marker move rather than forty.
• Order state applies by version, and any version at or below the applied one is ignored. This is what makes a replay after resume harmless.

The error most readers make here is applying messages the instant they arrive because the code is shorter. It is shorter until the first reconnect, at which point the difference between a resume and a replay becomes a user-visible duplicate.

Block 4. PURPOSE: design the failure behaviour, because that is the part of a live screen a user actually experiences.

• Reconnect with full jitter, doubling from a 1 s base to a 30 s cap, with the attempt counter reset only after a connection has survived 60 s. Authentication failures do not retry the stream, they refresh the credential once and then surface an error.
• Heartbeat every 20 s in both directions, connection declared dead at 45 s. Assumptions as derived above: two missed beats plus a margin.
• Chat sends queue in IndexedDB, so they survive a closed tab. Each entry holds the idempotency key, the payload, an attempt count and a created time. Entries older than a stated window surface to the user as failed rather than retrying forever.
• Degradation, stated before it is asked for: if the stream cannot be established at all, poll order state every 15 s, and replace the live map marker with the last known position plus the time it was recorded. A stale position labelled stale is useful. A stale position pretending to be live is a support ticket.

Result. Three streams separated by direction and loss cost, one transport chosen per direction with its cost stated, a receive path with sequences, gap detection and bounded deduplication, a send path that survives the tab, and a degradation mode that is honest about staleness. Nothing here required a WebSocket, and being able to say why is the point.

10e. Fade the scaffold

Faded example 1. Prompt: "Our live dashboard freezes for about two seconds every time the market opens." Blocks 1 to 3 are given. Produce block 4.

• Block 1: a freeze is main-thread occupancy, so the candidates are parse cost, state write cost, render cost or a layout loop, and they are distinguishable in one profile.
• Block 2: the profile shows thousands of short tasks rather than one long one, each a message parse followed by a state write followed by a render.
• Block 3: the rate at open is measured at roughly 4,000 messages a second against a screen showing 30 rows, so almost every message changes nothing visible.

Faded example 2. Prompt: "Users report seeing their own chat messages twice after driving through a tunnel." Blocks 1 and 2 are given. Produce blocks 3 and 4.

• Block 1: a duplicate after a connectivity gap is either a resend that the server accepted twice, or a single server-side message that the client rendered alongside its own optimistic copy.
• Block 2: the server log shows two stored messages with different ids and identical bodies, seconds apart, both from the same device.

10f. Check yourself

Q1. Your reconnect logic doubles from one second with no upper bound and no randomness. Describe both failure modes, and say what you would change.

Q2. After a reconnect, a client shows one message twice. Name the two independent mechanisms that both had to be absent, and say which one you would add first.

10g. When not to use this

Module 11. Performance

Time: 45 to 55 minutes reading, 35 to 45 minutes practice.

Performance answers fail in a specific way: the candidate lists metrics, then lists optimisations, and never connects one to the other. The connective tissue is that each metric blames a different part of the page, and each optimisation moves exactly one of them.

11a. Predict first

Read this artefact and commit to an answer before continuing.

+---------------------------------------------------------------+
| Product page. Two measurements taken the same week.           |
|                                                               |
| LAB, one run, desktop, wired, cold cache:                     |
|   TTFB 180 ms   FCP 0.9 s   LCP 1.2 s   TBT 40 ms   CLS 0.00  |
|                                                               |
| FIELD, 28 days, all users:                                    |
|   LCP p50 1.4 s   LCP p75 4.1 s   LCP p95 9.6 s               |
|   INP p75 480 ms                  CLS p75 0.19                |
|                                                               |
| Team's conclusion: "the lab says we are fast, field data is   |
| noisy, we will keep optimising LCP."                          |
+---------------------------------------------------------------+
Caption: one lab run and one field distribution for the same
page, with the team's reading of them.

Question. Name what the p50 to p75 gap tells you that the lab run cannot, and say which metric the team should work on first and why it is not LCP.

11b. The metric set, and what each one blames

Define the terms as you introduce them. All of these are measured from navigation start unless stated.

The blame column is the point. If LCP is bad, do not "optimise the page". Find the LCP element, then ask three questions in order: was it discoverable in the initial HTML, was it given a high enough priority, and was it large in bytes. Those three cover the large majority of LCP problems and they are answered by inspection, not by a tool.

TBT is a lab proxy for INP, not the same metric. TBT is measured with no user present, so it can only see potential blocking. A page with a 900 ms hydration task has terrible TBT and may have fine INP if the user does not interact during hydration. Use TBT as the CI gate, because it is deterministic. Use INP as the truth, because it has users in it.

11c. Lab versus field, stated as a division of labour

Making a lab run deterministic enough to gate on. A single lab run has variance measured in tens of percent. Three controls, in order of value:

• Run N times and take the median. N = 5 is the usual compromise: the median of 5 is much more stable than a single run and costs 5 minutes rather than 20.
• Pin the CPU throttle and the network profile explicitly, and record them in the result, so a result from a faster CI machine is not compared with an older one.
• Gate on two consecutive failing builds rather than one, which turns a 10 percent per run false alarm rate into about 1 percent.

Percentiles, and how much data a percentile needs

Averages hide the population you care about. Concrete distribution:

• 70 percent of sessions at 700 ms, 30 percent at 4,000 ms
• Mean = 0.7 x 700 + 0.3 x 4,000 = 490 + 1,200 = 1,690 ms
• p75 = 4,000 ms

The mean reads as a mildly slow page. The p75 reads as a page where three users in ten wait four seconds. Both numbers are correct. Only one describes a user.

How many samples does a p75 need? This is derivable and almost nobody derives it, so it is a strong thing to be able to do at a whiteboard.

The count of samples above the 75^th percentile is binomial with n trials and p = 0.25.

• Standard deviation of that count = sqrt(n x 0.25 x 0.75) = sqrt(0.1875 n)
• n = 1,000: sd = sqrt(187.5) = 13.7 samples
• Two standard deviations is 27 samples out of 1,000, which is 2.7 percentile points. So your "p75" is really somewhere between the p72.3 and the p77.7.

To convert that into milliseconds you need the local shape of your own distribution. If your measured values between p72 and p78 span 2,200 to 2,500 ms, then the 2.7 point wobble is about 135 ms of noise on a p75 near 2,350 ms, which is roughly 6 percent.

The operational consequence. A dashboard cell with 1,000 samples cannot detect a 5 percent regression. Either accumulate more samples per cell, or compare over longer windows, or accept that you are watching for large moves only. Say which one you chose.

Code splitting, priced

Two assumptions, both stated because everything below depends on them.

• Effective throughput 1.6 Mbps = 200 KB/s. This is a planning figure for a congested mobile connection. It is reasonable because it sits well below a clean 4G link and well above a genuinely bad one, so it will not flatter you.
• JavaScript main thread cost of roughly 1 ms per KB of uncompressed source on a mid tier phone, covering parse, compile and initial evaluation. Compressed JavaScript expands by roughly 3.3x, so 1 KB compressed is about 3.3 ms. Measure your own with a long task recording before quoting it.

Now price a bundle.

Now split by route. The checkout route needs 160 KB of the 420 KB.

• Saved bytes: 260 KB
• Saved transfer: 260 / 200 = 1.3 s
• Saved main thread: 260 x 3.3 = 858 ms
• Total saved: about 2.2 s, and roughly 40 percent of that saving is CPU, not network

That CPU share is the part people forget. On a fast network the same split still saves 858 ms, which is why "our users are on wifi" is not a reason to skip it.

Route splitting versus component splitting. They are not the same technique at different granularity, they have different failure modes.

The component split break even, derived. A dynamic import costs one additional round trip that cannot start until its parent chunk runs. Assume a 150 ms round trip on mobile, which is an ordinary figure for a warm connection to a CDN edge.

• A 20 KB compressed chunk transfers in 20 / 200 = 100 ms
• It costs 150 ms of round trip that the parent bundle would not have paid
• Net: you spent 150 ms to save 100 ms of transfer plus 66 ms of CPU (20 x 3.3), so it is roughly break even at 20 KB and clearly positive above about 40 KB

Below that, splitting a component is a loss dressed as an optimisation. This is the number to quote when someone proposes lazy loading every modal in the app.

A budget you can actually enforce

A performance budget fails in CI for one of three reasons: it is measured on the wrong thing, it is flaky, or nobody can get an exception so they disable it. Design against all three.

+---------------------+     +----------------------+
| BUILD               | ==> | BYTE BUDGET          |
| bundler stats file  |     | per route entry      |
| per route entry     |     | compressed bytes     |
+---------------------+     +----------+-----------+
                                       |
+---------------------+                |  fail or pass
| LAB RUN x5          | ==> +----------v-----------+
| fixed CPU throttle  |     | TIMING BUDGET        |
| fixed network       |     | median TBT, median   |
| median of 5         |     | LCP, 2 builds in a   |
+---------------------+     | row before failing   |
                            +----------+-----------+
                                       |
                            +----------v-----------+
                            | EXCEPTION PATH       |
                            | labelled PR, expiry  |
                            | date, owner          |
                            +----------------------+
Caption: two gates with different determinism, and the escape
hatch that keeps the gate from being deleted.

What to put a number on.

Set the initial number from where you are, not from a target. Take the current value, add 5 percent headroom, and freeze it. A budget set at an aspirational number fails on day one and is disabled by day three. Ratchet it down when a real improvement lands, in the same pull request that lands the improvement.

11d. Worked example

The prompt. "Our product detail page felt fine last quarter. Field INP p75 went from 210 ms to 480 ms over six weeks with no single obvious release. Diagnose and design the fix."

Inputs, stated before I touch anything:

Block A. Purpose: let the metric name the suspect before touching code

INP moved, LCP did not. That single fact eliminates a large space of causes. INP is input to next paint, so it blames one of three things: the event handler itself, the main thread being occupied when the input arrives, or the rendering work triggered by the handler.

I ask for the attribution breakdown that a modern RUM library records with each INP sample:

I do not guess between them. I say that the next thirty seconds of the interview depend on which of the three grew, and I ask.

The error most readers make here. Jumping to "we should code split". Code splitting reduces startup work. If the regression is in presentation delay from an over broad re-render, splitting changes nothing and you have spent a sprint.

Block B. Purpose: split the population instead of chasing the average

Suppose attribution says input delay grew from 60 ms to 300 ms. Main thread contention. Now I segment before optimising, because "the main thread is busy" has a dozen owners.

I cut the INP p75 by four dimensions, and I check each cell has enough samples to be readable. From 11d, a cell needs roughly 1,000 samples for a p75 with about 2.7 percentile points of wobble.

• 900,000 views per day
• Cut by 12 routes and 3 device classes = 36 cells
• 900,000 / 36 = 25,000 per cell per day, which is 25x the minimum. Comfortable
• Adding a fourth cut of 4 network classes gives 144 cells and 6,250 each, still fine
• Adding a fifth cut of 20 countries gives 2,880 cells and 312 each, which is below the readable threshold. I stop at four dimensions and say why

This arithmetic is the difference between a segmentation plan and a wish. It also tells me the honest limit of what my data can answer.

The error most readers make here. Slicing until something looks bad. With enough thin cells, something always looks bad, and it is noise. Decide the readable cell size first, then slice.

Block C. Purpose: attribute the cost to a specific line of the dependency graph

The segmentation says the regression is on all routes, all devices, worst on the slowest device class. All routes means shared code, not route code.

I compare the shared bundle across the six weeks:

92 KB compressed is about 304 KB uncompressed, about 304 ms of main thread on the assumed mid tier phone. That is in the right order of magnitude for a 240 ms input delay regression, so the hypothesis survives arithmetic.

Then I find where the 92 KB went, using the build's module attribution rather than intuition:

The error most readers make here. Reading total bundle size and stopping. The actionable unit is the module and its importer. "Our bundle grew" is not a finding. "An analytics wrapper transitively imports a date library" is.

Block D. Purpose: choose the cuts that pay, and price each one

Three candidate fixes, priced against the 1.6 Mbps and 1 ms per KB assumptions stated in the code splitting section.

I take the first two, which is 72 KB, about 360 ms of transfer and about 238 ms of CPU on the slow device class. The predicted input delay improvement is in the same range as the observed regression, which is the check that I am fixing the thing I diagnosed.

I decline the third explicitly and say why, because declining a plausible optimisation with a number is a stronger signal than accepting all three.

The error most readers make here. Treating byte savings and CPU savings as one number. They land on different users. On a fast network with a slow phone the CPU saving is the entire benefit, and that population is large.

Block E. Purpose: make the fix permanent with a gate that will not be flaky

The regression took six weeks and no single release, which means it was 15 merges each adding a few kilobytes. A one time fix will be undone by the same process. So the deliverable is a gate, not a diff.

Plus one non gate: a weekly report of the largest module additions by compressed bytes, sent to the team, because the failure mode here was invisibility rather than negligence.

The error most readers make here. Gating on field INP. Field data arrives days after the deploy and is a distribution, so it cannot fail a build. Field data alerts. Lab data gates.

11e. Fade the scaffold

Fade 1: an internal analytics dashboard. 4,000 daily users, all on company issued laptops on office wifi, one route, heavy client side charting over tables of up to 50,000 rows. Complaint is "filtering feels laggy". Same five block shape, last block blank.

• Block A, let the metric name the suspect: INP again, but the attribution here is likely presentation delay rather than input delay, because the handler triggers a re-render of a large table. Confirm before acting.
• Block B, split the population: with 4,000 users on one route there are no meaningful segments and, by the percentile arithmetic above, a p75 on 4,000 samples per day has about sqrt(0.1875 x 4000) = 27 samples of standard deviation, so 2 sd is 54 out of 4,000, only 1.4 percentile points. The data is readable in aggregate but there is nothing to slice. Segment by row count in the current view instead, which is the variable that actually differs.
• Block C, attribute the cost: not bytes. On fast laptops and fast wifi a 400 KB bundle costs about 0.13 s of transfer and, at roughly a third of mid tier phone cost, about 0.44 s of CPU once. The recurring cost is per interaction: 50,000 rows re-rendered on every keystroke of the filter input.
• Block D, choose the fixes and price them: virtualise the table so only the roughly 40 visible rows render, which turns a 50,000 element render into 40. Debounce the filter input at about 150 ms so a 10 character query does 1 render rather than 10. Move the filter computation off the main thread only if profiling shows the computation, not the render, dominates.
• Block E, make it permanent: you write this block.

Fade 2: a marketing landing page. Server rendered, mostly static, one hero image, a video embed, three third party tags (consent, analytics, a chat widget). Field LCP p75 is 4.8 s, CLS p75 is 0.31, INP p75 is 140 ms. Last two blocks blank.

• Block A, let the metric name the suspect: LCP and CLS are both bad while INP is fine, which is the opposite pattern to the worked example. That combination points at content arriving late and shifting layout, not at main thread occupancy.
• Block B, split the population: check whether LCP p75 differs between users who accepted and declined the consent dialog, because the dialog gates the tags and therefore creates two structurally different pages.
• Block C, attribute the cost: you write this block.
• Block D, choose the fixes and price them: you write this block.

11f. Check yourself

Q1. A colleague reports that a change improved lab LCP from 2.4 s to 1.6 s, measured once before and once after. Field LCP p75 is unchanged after two weeks. Give two distinct explanations and say how you would tell them apart.

Q2. Your team proposes lazy loading every dialog in the application, of which there are 30, averaging 12 KB compressed each. Evaluate with numbers.

11g. When not to use this

Component level code splitting.

A field RUM pipeline with attribution.

A performance budget enforced in continuous integration.

Virtualisation of a list.

Module 12. Design systems

Time: 30 to 40 minutes reading, 20 to 30 minutes practice.

A design system interview question is rarely "build a button". It is "40 engineers across 6 apps need to ship a rebrand in one quarter". That is a versioning, distribution and governance problem wearing a visual costume.

12a. Predict first

Read this artefact and commit to an answer before continuing.

+---------------------------------------------------------------+
| Component library, 30 components, shipped 18 months ago.      |
| Inside Button.css, colours written as raw hex:                |
|   background 1E5AA8   text FFFFFF   border 17457E             |
| Inside Card.css:                                              |
|   background FFFFFF   border D7DBE0                           |
| 27 of the 30 components contain literal hex values.           |
|                                                               |
| New requirement: ship a dark theme and a high contrast theme. |
+---------------------------------------------------------------+
Caption: a component library with colour values written directly
into component styles, and the requirement that breaks it.

Question. Count the edits the naive fix requires, then say why the usual advice ("extract the colours into variables") is only half the fix.

12b. Token architecture in three layers

Define each layer by who is allowed to reference it.

The single rule that makes the architecture work. A component may never reference a primitive. If it does, the primitive's name has become part of the component's contract, and the theme layer can no longer intervene.

Enforce it mechanically: a lint rule that fails on any primitive token name appearing outside the semantic token file. Without enforcement this rule decays in about two quarters, because referencing grey-200 directly is always the fastest way to close one ticket.

Counting a realistic system.

That last row is a judgement: component tokens are an escape hatch, not a tier you populate on principle. A component that needs six of its own tokens is usually a component whose semantic roles are missing.

+-------------------+
| PRIMITIVES        |
| blue-600 grey-200 |
| space-4 radius-2  |
+---------+---------+
          | referenced only by
          v
+-------------------+     +----------------------+
| SEMANTIC ROLES    | <== | THEME FILES          |
| surface           |     | light, dark, contrast|
| text-primary      |     | each redefines the   |
| action-bg         |     | same 45 role names   |
+---------+---------+     +----------------------+
          | referenced by
          v
+-------------------+
| COMPONENTS        |
| Button Card Input |
| no hex, no        |
| primitive names   |
+-------------------+
Caption: the reference direction between token layers, and where
a theme intervenes. Arrows point from definition to consumer.

12c. Theming without a flash

The flash of the wrong theme happens because the server does not know the user's preference at the moment it produces the HTML. Four ways out, and they differ on a dimension people forget: cache friendliness.

The trade nobody states. The server cookie approach is the most robust and it makes the document uncacheable at the shared cache layer, because two users now get different bytes. On a page whose main performance asset is a fully cached HTML document, that is a real cost.

Three ways to have both, in increasing complexity:

• Vary the cached document on a single small cookie whose value has only two or three possibilities. Cache hit rate falls by the number of variants, not by the number of users.
• Keep the document shared and cached, and set the theme class from a blocking inline script. Cost: about 1 ms of parser blocking and a synchronous storage read, and it does not work with JavaScript disabled.
• Ship both themes as CSS that responds to a single attribute, and let an edge worker inject the attribute from the cookie into an otherwise cached document. Cost: an edge compute dependency.

Measure the flash before you pay for any of this. The framework effect approach produces a visible wrong theme for the interval between first paint and hydration completing. If that interval is 80 ms on your fastest population and 600 ms on your slowest, the slowest population sees a clearly perceptible flash and the fastest does not. That distribution decides how much you should spend.

Variant design, or how a component API stops scaling

The prop explosion is arithmetic. A button with 5 intents, 3 sizes and 2 emphases has 5 x 3 x 2 = 30 combinations. Almost certainly fewer than 30 are designed, so the API allows states nobody has drawn.

Prefer the third. The value is not correctness for its own sake: it is that the type error routes an undesigned request to a designer instead of to a CSS override in a product repo.

When props are the wrong tool entirely. If a component accumulates props that only exist to reach inside it (showHeaderIcon, headerIconSize, footerAlignment), the component wants composition instead. Expose named slots or compound children, and let the consumer place elements. The signal to watch for is a prop whose only job is to conditionally render another component.

Versioning and deprecation of a library

Semantic versioning was designed for programmatic contracts and a component library also has a visual contract, which semver has no slot for. State a policy explicitly, because "is this a breaking change" is the question that consumes the most time in a design system team.

The 2 px threshold is a choice, not a law. The reason it is reasonable: below about 2 px, consumers' visual regression tests will pass under ordinary anti aliasing tolerance, and above it they will fail. Setting the policy threshold at the point where it becomes visible to your consumers' tooling is what makes it enforceable. Pick your own from your own tolerance settings.

A deprecation clock with dates, not intentions.

1. Release N: the replacement ships. The old component still works, unchanged.
2. Release N: documentation marks the old one deprecated and links the replacement. A codemod ships with it if the change is mechanical.
3. Release N+1: a development only console warning fires once per component per session. Never in production, because it is noise in a consumer's error tracking that they cannot fix on your schedule.
4. Removal: no earlier than the next major, and no earlier than 6 months after step 1, whichever is later.

The "whichever is later" clause is what makes it credible. A team that ships majors monthly would otherwise give consumers four weeks.

Adoption measured, not assumed. Two numbers, both from a static scan of consumer repositories:

• Share of component instances imported from the library versus locally reimplemented. Falling share means the library is not meeting a need, and the reimplementations tell you which.
• Count of consumer stylesheets that target the library's internal class names. Each one is a bug report you never received, and each one breaks on your next internal refactor. This number is the single best early warning that your API is too closed.

12d. Worked example

The prompt. "We have a 30 component library used by 6 applications. We need to ship a high contrast theme for an accessibility commitment in one quarter, and the brand team wants a colour refresh in the same window."

Inputs, stated before I touch anything:

Block A. Purpose: separate the two requests, because they are not the same work

The brand refresh and the high contrast theme sound like one project and they are not. I split them in the first two minutes:

• A brand refresh changes primitive values. If the token architecture is right, it is an edit to one primitives file.
• A new theme changes semantic role definitions. It is a new theme file plus, critically, decisions about what each role means in that theme.

Both are blocked by the same prerequisite: 27 components must stop containing literal values. That prerequisite is the project. The two requests are each about a day of work once it is done.

Saying this reframes the estimate from "two projects in a quarter" to "one migration plus two small deliverables", which is both more honest and more achievable.

The error most readers make here. Starting with the theme file. You can write a beautiful dark theme and it will change nothing, because 27 components are not listening.

Block B. Purpose: size the migration before committing to a date

• 27 components x 2 to 4 hours = 54 to 108 hours
• 3 engineers, and assume 50 percent of their time goes to the migration because support and bug fixes do not stop. That is 60 hours per week x 0.5 x 3 = 60 hours per week of migration capacity: 3 engineers x 20 hours = 60 hours per week
• 54 to 108 hours of work at 60 hours per week is 1 to 2 weeks

That result is suspiciously comfortable, which is the moment to look for what the estimate excludes. Three things it excludes:

Revised: roughly 2 weeks of naming, 2 weeks of migration, 2 weeks of theme authoring and contrast verification, leaving 6 weeks of buffer for consumer adoption in a 12 week quarter. That is a plan. The first number was an estimate.

The error most readers make here. Estimating the mechanical work and presenting it as the project estimate. The mechanical work is almost never the long pole in a design system migration. Naming and agreement are.

Block C. Purpose: design the semantic layer against the hardest theme first

I author the role names against the high contrast theme, not against the current light theme. The reason is that high contrast is the most constrained: it forces every role pair to satisfy a contrast requirement, and it exposes any place where colour alone was carrying meaning.

Concretely, this catches things like:

• A disabled state expressed only as reduced opacity. In high contrast that must become a distinct border or pattern, so the role set needs a border-disabled, which nobody would have invented from the light theme.
• A selected row expressed as a pale tint. High contrast needs an explicit selected border role.
• An error field expressed only as a red border. That is a colour only signal in any theme and it needed an icon and text regardless. The theme work surfaced an existing accessibility defect.

I say that last one out loud, because "this migration will surface accessibility defects that exist today" sets an expectation that protects the schedule later.

The error most readers make here. Deriving semantic roles from the current light theme by mechanical extraction. You get names like surface-f5f5f5, which is a hex value with extra steps, and the constrained themes then have no vocabulary for the distinctions they need.

Block D. Purpose: get 6 independent applications onto it without a flag day

Six consumer apps with six release trains means there is no date on which everyone upgrades. So the migration must be non breaking at every step.

The sequence, and why each step is safe:

Steps 1 through 3 are all non breaking, which means the entire enabling work can land without coordinating six teams. Only step 4 needs a conversation, and by then the mechanism is proven.

The error most readers make here. Bundling the enabling refactor with the visible change in one major release. It maximises the blast radius of the riskiest step and it makes any visual bug ambiguous between the refactor and the rebrand.

Block E. Purpose: keep it from decaying after the quarter

Three mechanisms, each cheap, each addressing a specific decay path.

I explicitly do not propose a review process or a governance council, because those depend on attention and the mechanisms above do not.

The error most readers make here. Ending at the migration. A design system that is correct on the day it ships and unmaintained after is worse than no system, because six teams have now coupled to it.

12e. Fade the scaffold

Fade 1: adding a second brand. The same library must serve two products with different palettes, different type scales and different border radii, sharing all behaviour. Same five block shape, last block blank.

• Block A, separate the requests: two brands is a primitives problem if the two brands agree on roles, and a semantics problem if they do not. Check first whether both brands have the same concept of, say, a raised surface. If yes, one semantic layer with two primitive sets. If no, you have two design systems sharing components, which is a much larger claim.
• Block B, size it: the type scale and radius differences mean primitives beyond colour must also be tokenised. Count them: about 30 non colour primitives from 12b, and any component with a hard coded pixel value needs the same treatment the colours got.
• Block C, design against the hardest case: the brand with the larger type scale, because larger type is what breaks fixed height components, truncation and dense layouts. Designing against the compact brand first hides every overflow bug.
• Block D, adopt without a flag day: brand two is purely additive, so every step is non breaking by construction. The risk is not release management, it is that brand two's components look subtly wrong in ways brand one never revealed.
• Block E, keep it from decaying: you write this block.

Fade 2: deprecating a widely used component. A Dropdown component used in about 400 places across 6 apps must be replaced by a Select with a different API and a different accessibility model. Last two blocks blank.

• Block A, separate the requests: there are two here, an API migration and a behaviour change. The accessibility model change means the replacement is not a drop in even where the API matches, so a codemod can move the call sites but cannot verify the result.
• Block B, size it: 400 call sites. A codemod handles the mechanical share, and the estimate turns on what fraction is mechanical. If 80 percent are simple usages, the codemod moves 320 and 80 need a human, at say 30 minutes each, which is 40 hours spread across 6 teams.
• Block C, design against the hardest case: you write this block.
• Block D, adopt without a flag day: you write this block.

12f. Check yourself

Q1. A consumer team reports that your patch release broke their screenshot tests. Your change was a 1 px adjustment to a card's internal padding. Who is wrong, and what do you change?

Q2. Your library defines 180 component level tokens across 30 components. Give the two most likely diagnoses and what each implies.

12g. When not to use this

A three layer token architecture.

A separately versioned, published component library.

A codemod shipped with a breaking change.

A high contrast theme as a separate theme.

Module 13. Micro-frontends, honestly

Time: 30 to 40 minutes reading, 20 to 30 minutes practice.

This module is deliberately structured to help you say no. Micro-frontends solve an organisational problem at a technical cost, and the interview signal is whether you can price that cost rather than whether you can name three integration strategies.

13a. Predict first

Read this artefact and commit to an answer before continuing.

+---------------------------------------------------------------+
| One page composes the shell plus 3 of 4 deployed apps.        |
| Compressed bytes each app ships, by part:                     |
|                                                               |
|   SHELL     framework 45  router 12  design system 60         |
|   CATALOG   framework 45  router 12  design system 60  app 90 |
|   CART      framework 45  router 12  design system 58  app 40 |
|   REVIEWS   framework 44  router 12  design system 60  app 35 |
|                                                               |
| The user loads SHELL + CATALOG + CART + REVIEWS.              |
+---------------------------------------------------------------+
Caption: four independently built bundles broken into shared
libraries and unique application code.

Question. Compute the duplicated bytes, convert them to seconds using 200 KB/s of throughput and 1 ms of main thread per KB of uncompressed source at 3.3x expansion, then name the one number in the table that blocks the obvious fix.

13b. Five integration strategies, compared on what actually differs

Define the terms. Integration here means how code from independently deployed teams ends up executing on one page. Version skew means two apps needing different versions of the same library at the same time.

The pattern in that table. Every column trades against isolation. The strategies that isolate best (iframes) duplicate most and communicate worst. The strategies that share best (build time packages) remove the deploy independence that was the reason to do this at all.

The dishonest middle. Runtime federation with aggressive singleton sharing markets itself as having both. It does not. It converts the duplication cost into a coordination cost, which is less visible and often larger.

Quantify the coordination cost. With N apps and S shared singletons, every singleton upgrade requires agreement across N teams, so the coupling surface is N x S pairs.

• 4 apps, 3 singletons (framework, router, design system) = 12 pairs
• A framework major upgrade needs 4 teams to schedule work in the same window
• The team that cannot schedule it blocks the other three

That last line is where the architecture is decided. If your organisation can coordinate 4 teams on a version bump, you probably did not need micro-frontends. If it cannot, your singletons will skew and you will pay the duplication anyway.

13c. The three problems that are not about bundling

Routing ownership. The URL is a shared global namespace, so it needs an explicit owner and an explicit contract.

+-------------------------------------------------------------+
| SHELL owns the prefix table and nothing below it            |
|   /catalog/*   ==> CATALOG app                              |
|   /cart/*      ==> CART app                                 |
|   /reviews/*   ==> REVIEWS app                              |
|   /            ==> SHELL home                               |
+------------------------------+------------------------------+
                               |
        +----------------------+----------------------+
        v                      v                      v
+---------------+     +---------------+     +---------------+
| CATALOG owns  |     | CART owns     |     | REVIEWS owns  |
| every path    |     | every path    |     | every path    |
| under its     |     | under its     |     | under its     |
| prefix, and   |     | prefix        |     | prefix        |
| may not read  |     |               |     |               |
| others        |     |               |     |               |
+---------------+     +---------------+     +---------------+
Caption: a prefix table owned by the shell, with each app owning
its own subtree and no app reading another app's paths.

Two rules that prevent most routing incidents:

• An app may only construct links into another app through a shell provided function, never by string concatenation. Otherwise a prefix change in one team breaks links in three others silently.
• Deep links must work on a cold load. If arriving directly at /reviews/product/17/page/3 requires the catalog app to have run first, you have a hidden dependency that only appears in shared links and search results.

Cross app authentication, and the isolation myth. State this plainly in an interview because it is where confident answers go wrong.

The workable pattern for trusted first party apps: the shell holds the token in a closure in memory and exposes an async getToken() through the mount contract. Apps never touch storage. This does not create a security boundary, and its actual benefit is that refresh, expiry and logout have exactly one implementation instead of four.

Error isolation, built rather than assumed. Four mechanisms, cheap, in the order they pay off:

The timeout number is a choice and here is the reason 3 s is defensible: it is above the point where a slow but functioning CDN edge would resolve, and below the point where a user concludes the page is broken. Set yours from your own remote entry latency distribution.

13d. Worked example

The prompt. "We have one large e-commerce front end. Four teams work in it. Releases are weekly and every release requires all four teams to sign off. The vice president wants micro-frontends. Design it, or tell them not to."

Inputs, stated before I touch anything:

Block A. Purpose: find out what problem is actually being solved

I do not design anything yet. I ask what improves if this works, and I try to get a number for it.

The strongest number here is 5 of 7 rollbacks caused by another team. That is a real coupling cost. I say out loud that it is also the number most likely to get worse, because a runtime integration failure is harder to catch before production than a build failure.

The error most readers make here. Designing the architecture that was asked for. The question contains "or tell them not to" and the interviewer put it there on purpose. An answer that never evaluates the premise scores lower than one that evaluates it and then proceeds.

Block B. Purpose: price the cheaper alternative honestly first

The cheaper alternative is a modular monolith with enforced boundaries. I price both against the actual complaint, which is the coordinated release.

The middle option deserves the emphasis. The complaint is that a release requires four sign offs. Flags decouple "my code is live" from "my feature is on", which removes most of the sign off pressure without splitting the deployment unit.

I would recommend the middle option, and I say what would change my mind: if teams need to deploy at genuinely different cadences (one team shipping hourly, another quarterly for regulatory review), flags do not help and separate deployment units do.

The error most readers make here. Presenting the cheap option as a strawman. Price it properly, including what it does not solve, or the recommendation is not credible.

Block C. Purpose: design it properly if the premise survives

Assume the interviewer says the regulatory case is real: one team ships weekly, one ships after a compliance review that takes a month. Now separate deployment units are justified, and I design.

Choices, each with the reason:

I explicitly bound the number of apps at four and say why: the coordination surface is N x S, so adding apps grows coupling linearly while adding no new independence for the teams that already have it.

The error most readers make here. Sharing everything as a singleton because duplication looks bad on a chart. Forcing the design system to one version recreates the coordinated release you just spent a quarter escaping, in a place where it is harder to see.

Block D. Purpose: make the runtime failure modes visible before they happen

Splitting the deployment unit converts a class of build errors into a class of production errors. I name them and design for each.

The last row is the one that is usually discovered too late. With one deployment unit, an error's build identifier tells you exactly what code is running. With four, you need four, reported together, or your error tracking becomes guesswork during an incident.

The error most readers make here. Treating observability as a later phase. In this architecture attribution is the product of the design, not an add on: if the build identifiers are not in the contract from day one, they arrive after the first incident that needed them.

13e. Fade the scaffold

Fade 1: an internal admin console. Three teams, 9 engineers total, one deploy pipeline, no regulatory constraint, current bundle 280 KB compressed, and the stated complaint is "our builds take 4 minutes". Same four block shape, last block blank.

• Block A, find the real problem: the complaint is build time, and the input contains no release coupling and no independence requirement. Build time is a build tooling problem. Ask what the 4 minutes consists of before anything else.
• Block B, price the cheaper alternative: incremental builds, a shared build cache and project references typically address this at a cost of days. A micro-frontend split addresses it at the cost of a quarter and adds runtime failure modes that a 9 person team now has to operate.
• Block C, design it if the premise survives: the premise does not survive. Nine engineers across three teams is below the threshold where deploy independence buys anything, and the console is internal so the 100 KB or more of duplication is genuinely cheap. The recommendation is no.
• Block D, make the failure modes visible: you write this block.

Fade 2: unwinding an existing split. An organisation has 6 micro-frontends, built 3 years ago by a team that has since left. Two are actively developed, four change roughly once a year. Page load ships 5 copies of a framework. Last two blocks blank.

• Block A, find the real problem: the architecture is being paid for by every user on every page load, and the independence it buys is used by 2 of the 6 apps. The mismatch between where the cost falls and where the benefit lands is the finding.
• Block B, price the alternative: merging the 4 low change apps into one deployment unit removes 4 remote loads and 3 duplicate framework copies. At 45 KB per copy that is 135 KB compressed, about 0.68 s of transfer at 200 KB/s plus about 0.45 s of CPU at the stated assumption. The 2 active apps keep their independence.
• Block C, design the target state: you write this block.
• Block D, make the failure modes visible: you write this block.

13f. Check yourself

Q1. A team proposes micro-frontends and says the main benefit is that each team can pick its own framework. Give the strongest version of their argument and then your response.

Q2. Your shell forces a single version of the design system. A team blocks a release because a design system major broke their app. What does this tell you about the architecture, and what would you change?

13g. When not to use this

Micro-frontends at all.

Forced singleton sharing of a library.

Iframes as the integration strategy.

A shell provided authentication service.

Module 14. Security in the browser

Time: 45 to 55 minutes reading, 30 to 40 minutes practice.

Browser security questions are graded on whether you can reason about a trust boundary, not on whether you can list acronyms. The organising question for the whole module: which code executes in my origin, and what can it reach?

14a. Predict first

Read this artefact and commit to an answer before continuing.

+---------------------------------------------------------------+
| Comment rendering, in production:                             |
|   el.innerHTML = renderMarkdown(comment.body)                 |
|                                                               |
| Response header on every page:                                |
|   Content-Security-Policy: default-src 'self';                |
|     script-src 'self' 'unsafe-inline' cdn.partner.example     |
|                                                               |
| Session credential: a signed token in localStorage,           |
|   attached by the client as an Authorization header.          |
+---------------------------------------------------------------+
Caption: a rendering sink, a content security policy, and a
credential storage choice, all shipped together.

Question. Rank the three by contribution to the worst case outcome, and say specifically what the policy header is worth against this particular defect.

14b. Cross-site scripting, organised by sink

Definition. Cross-site scripting is any path by which text controlled by an attacker becomes code executing in your origin.

Three delivery routes:

The sinks are the short list worth memorising. Everything else is a path to one of these.

The defence order that actually works.

1. Default to text. Frameworks that escape by default are doing the heavy lifting. The remaining risk is concentrated in the escape hatches, which is a list you can enumerate and lint for.
2. Sanitise at the sink, not at the source. Input validation is worth doing for other reasons and it does not solve this, because the same stored value may be rendered into HTML, into an attribute, into a URL and into JavaScript, and each needs a different treatment.
3. Use a vetted sanitiser, never a regular expression. Parsing HTML with a pattern fails in ways that are well known to attackers and surprising to everyone else.
4. Enforce mechanically with a Trusted Types policy where supported, which converts every dangerous sink into a type error unless the value passed through an approved factory. This turns an audit into a compile time and runtime guarantee.

14c. Content security policy, and how to roll one out

A policy is a per response header that tells the browser what sources are allowed for each resource type.

Allowlists versus nonces. An allowlist of hosts is easy to write and weak, because you inherit every script any allowlisted host will serve, including old library versions and any endpoint that reflects a caller supplied callback name.

A nonce based policy is stronger: the server generates a random value per response, the policy accepts scripts carrying it, and injected markup cannot guess it. Add 'strict-dynamic' so scripts loaded by a trusted script are also trusted, which is what makes a nonce policy survive contact with a real bundler.

Three constraints to state honestly:

• The nonce must be per response and unguessable, which means the HTML document cannot be a statically cached file without an edge step to inject it.
• If a nonce is present, browsers that support nonces ignore 'unsafe-inline', so it can stay for older clients without weakening the modern ones. Say this, because it is the sentence that unblocks most rollouts.
• Any inline event handler attribute in your own markup will break. That is the actual migration cost, and it is worth counting before promising a date.

A rollout plan with numbers.

The extension noise in phase 2 is the part that surprises people and it is why report only must run long enough to characterise the baseline. Skipping straight to enforcement breaks pages for a population you cannot identify.

Request forgery, framing and cross-origin rules

Cross-site request forgery, stated as a mechanism. The browser attaches cookies to requests based on the destination, not on who initiated them. So a form on an attacker's page can cause an authenticated state changing request to your origin. The attacker cannot read the response, which is why forgery targets writes rather than reads.

Two rules that make this simple: never make a state changing endpoint reachable by GET, and set SameSite explicitly rather than relying on a default.

Clickjacking. An attacker frames your page transparently over their own interface so a click lands on your control. The defence is frame-ancestors in the policy header, with the legacy frame options header alongside it for older clients. Framing defences are per response, so any endpoint that returns HTML needs them, including error pages.

Cross-origin resource sharing, and what it is not. State this precisely because it is the most misunderstood item in the module.

Cookie attributes, each with the attack it addresses.

Token storage, priced against the two threats.

The honest summary: no storage choice survives script execution in your origin unharmed. The choice determines whether an injection is an active session compromise or a portable credential theft, and that is worth choosing deliberately.

14d. Worked example

The prompt. "Our analytics product lets customers write dashboard descriptions in markdown and embed an image by URL. Enterprise customers also want to embed our dashboards in their own intranet pages. Design the browser security posture."

Inputs, stated before I touch anything:

Block A. Purpose: draw the trust boundary before choosing any control

I state what executes in my origin and what it can reach, because every later decision follows from this one picture.

The uncomfortable row is the second. Two third party scripts already have the same power as our own code, so any control I design must account for scripts I did not write and cannot audit. This is the sentence that justifies the effort in the later blocks.

The error most readers make here. Treating third party tags as outside the threat model because they are from reputable vendors. Reputation is not a boundary. The boundary is the origin, and they are inside it.

Block B. Purpose: fix the sink, because the policy cannot save a broken sink

Order of work, and the reason for the order:

1. Configure the markdown renderer to not pass through raw HTML. This removes the large majority of payloads at almost no cost.
2. Sanitise the rendered output with a vetted sanitiser before it reaches the DOM, because renderer configurations regress and a defence that depends on one option staying set is not a defence.
3. Constrain the image URL: allow only http and https schemes, and reject anything else. A raw URL from a user reaching an src attribute is a separate sink from the markdown body.
4. Enable Trusted Types with a single approved policy that runs the sanitiser, so any new code path that reaches a raw HTML sink fails loudly rather than silently shipping.

Step 4 is what makes this durable. Steps 1 to 3 fix today's code. Step 4 fixes next year's code, written by someone who has not read this design.

The error most readers make here. Sanitising on write, when the comment is stored. The same stored value will later be rendered into HTML, into an attribute and possibly into a URL, and each context needs different treatment. Sanitise where the context is known, which is the sink.

Block C. Purpose: reduce what a successful injection is worth

Even with the sinks fixed, I assume an injection eventually happens, because two third party scripts are already privileged. So I reduce the payoff.

I note the trade explicitly: moving to cookies swaps an exfiltration risk for a forgery risk, and forgery has better established defences. That is why the trade is worth making, and saying it that way shows the reasoning rather than the conclusion.

The error most readers make here. Adding the cookie and forgetting that the credential is now attached automatically to every request the browser makes to the origin, including ones initiated by other sites. The forgery defence is not optional after this change, it is created by it.

Block D. Purpose: ship a policy that is worth its header bytes

Target policy, with a reason for each part:

• script-src with a per response nonce plus 'strict-dynamic', so our bundler loaded chunks work and injected markup cannot execute.
• object-src 'none' and base-uri 'self', both unconditional and both cheap.
• require-trusted-types-for 'script', which pairs with Block B step 4.
• form-action 'self', so an injected form cannot post user input elsewhere.
• frame-ancestors handled in Block E, because it is the enterprise embedding requirement rather than a policy detail.

Rollout, with the four phases and their durations from earlier in this module: report only for 2 weeks, a triage week, fixes, then enforce. I set the expectation up front that most report only volume will be browser extensions, which we neither fix nor allowlist.

The migration cost I flagged as unknown in the inputs is now the thing to measure first: count inline event handler attributes and inline script blocks in our own templates. That count is the schedule.

The error most readers make here. Adding a nonce while leaving 'unsafe-inline' out for older clients and then panicking when a legacy browser breaks. Keep 'unsafe-inline' alongside the nonce: nonce aware browsers ignore it, and older ones fall back to the weaker but functional behaviour.

Block E. Purpose: allow enterprise framing without allowing everyone

40 enterprise accounts want to frame our dashboards, so frame-ancestors 'none' is not available. Three options, and I pick one:

Two additions that make the chosen option safe:

• Domains are configured per account and validated, not free text, because a header built from unvalidated customer input is an injection into a security control.
• Any interactive control inside the embedded view that performs a destructive action requires a confirmation step, because framing defences protect the accounts that configured correctly and a confirmation protects the rest.

The error most readers make here. Treating framing as a single global setting. It is a per response decision and it can be per account, which is what turns an impossible requirement into a configuration.

14e. Fade the scaffold

Fade 1: a marketing site adding a tag manager. The marketing team wants a third party tag manager so they can add scripts without engineering involvement. The site has a newsletter form and no login. Same five block shape, last block blank.

• Block A, draw the trust boundary: a tag manager is a mechanism for injecting arbitrary script into your origin, controlled by whoever has access to its console. The trust boundary now includes that vendor's access control and every marketing person with a login.
• Block B, fix the sink: the sink here is the tag manager itself, and it cannot be sanitised. The equivalent move is to constrain what it can add: use the vendor's own restrictions where they exist, and put the tag manager on a separate subdomain so cookies scoped with the __Host- prefix are not shared.
• Block C, reduce what an injection is worth: there is no session credential, so the valuable target is the newsletter form input and any payment or lead data. form-action 'self' becomes a high value directive here, because the realistic attack is an injected form or an altered form action exfiltrating submissions.
• Block D, ship a policy: a nonce policy is in direct tension with a tag manager, because the whole product is inline injection. The honest options are to give the tag manager a nonce (which grants it full privilege, so the policy protects against everything except the largest risk) or to refuse the tag manager.
• Block E, the framing and embedding question: you write this block.

Fade 2: migrating an application from token in storage to cookie. A shipped single page application with a separate API origin, 200,000 daily users, moving from a bearer token in localStorage to an HttpOnly cookie. Last two blocks blank.

• Block A, draw the trust boundary: the application origin and the API origin are different, which is the fact that makes this migration non trivial. A cookie set on the API origin is third party to the application in some browser configurations, so the migration may require moving the API under a shared parent domain.
• Block B, fix the sink: unchanged from the current posture, and worth auditing during the migration because the whole justification for the work is reducing injection payoff.
• Block C, reduce what an injection is worth: this is the migration itself. HttpOnly, Secure, SameSite=Lax, __Host- prefix where the path and domain constraints allow it, and a short lifetime with a refresh endpoint.
• Block D, ship a policy: you write this block.
• Block E, the cross-origin and forgery consequences: you write this block.

14f. Check yourself

Q1. A colleague argues that input validation on the server makes output sanitisation unnecessary, since nothing dangerous is ever stored. Give the technical reason they are wrong and one operational reason.

Q2. Your policy is enforcing with a nonce and strict-dynamic. An engineer reports that a new feature does not work and asks to add 'unsafe-eval'. Diagnose and give two alternatives.

14g. When not to use this

A strict nonce based content security policy.

Trusted Types enforcement.

Moving a credential from storage into an HttpOnly cookie.

A separate embed origin for third party framing.

Module 15. Internationalisation

Time: 30 to 40 minutes reading, 20 to 30 minutes practice.

Internationalisation appears in frontend rounds as a constraint on an otherwise familiar design, and it is a good discriminator because the wrong answers are confidently wrong. Putting strings in files is the obvious half of the problem. What a plural rule does to a component API is the half that decides the design.

15a. Predict first

Read this artefact and commit to an answer before continuing.

+---------------------------------------------------------------+
| Message assembly:                                             |
|   t("You have ") + count + t(" new messages")                 |
| Locales shipped: en, de, ar, pl, ja                           |
| Bundle: all 5 locales, all 800 messages, in the main chunk    |
| Dates rendered with: date.toLocaleDateString()                |
| Future events stored as: 2026-11-01 09:30 with offset +01:00  |
+---------------------------------------------------------------+
Caption: four internationalisation decisions in one screen of a
shipped application.

Question. Name a distinct defect in each of the four lines, and put a number on the bundle one.

15b. Messages, plurals and why concatenation cannot be patched

A message format is a small language for describing a translatable string with placeholders, plural selection and gender selection inside it, so the translator controls the whole sentence.

The critical property is that selection lives inside the message, not in the calling code. The moment your component decides which of two strings to use, you have hard-coded a two-category plural rule into logic that cannot be translated.

Plural categories, which is the fact that settles the argument. The Unicode locale data defines up to six categories: zero, one, two, few, many, other. Languages use different subsets.

Two consequences that shape the API:

• A component that accepts singular and plural props has a two category assumption in its signature. It cannot be fixed by translation, only by an API change.
• The categories are not about the number's size. Polish uses "few" for counts ending in 2, 3 or 4 except in the teens, so the rule is arithmetic on the number, which is exactly why it belongs in locale data rather than in your code.

Markup inside translated text. Never split a sentence to wrap part of it in a link or bold. Put a tag placeholder in the message and let the rendering layer supply the element. Splitting produces the same word order problem as concatenation and it produces translation fragments no translator can work with.

Context and disambiguation. The same source word can need different translations, for example a noun and a verb spelled identically in English. Message identifiers should carry a context note, and the extraction tooling should surface it. This is cheap to build in and impossible to retrofit once translators have delivered.

15c. Direction, and what mirrors

Definitions. A right to left locale renders text from right to left and, by convention, mirrors the whole interface layout. Logical properties describe positions relative to the reading direction (start and end) instead of the screen (left and right).

The mechanical change is to stop naming physical sides.

Set dir on the document from the active locale and the browser does the rest for anything expressed logically. That is the whole technique, and it is why adopting logical properties before you have a right to left locale is cheap insurance rather than speculative work.

What does not mirror, which is the part people get wrong.

Bidirectional isolation. When a user supplied name in one direction is embedded in a sentence in the other, the text can visually reorder in ways that change meaning. Wrap user supplied strings in an isolation element or apply isolation styling. This is a two character fix for a class of bug that is very hard to diagnose from a screenshot.

Formatting, time and bundle shape

Use the platform formatters, and always pass the locale explicitly. The browser ships locale data for number, currency, date, time, relative time, sorting, list joining and plural rules. Reimplementing any of these is both larger and less correct.

Time, stated as three rules.

1. A past or fixed instant is stored as an instant in UTC. Rendering applies a zone at display time.
2. A future event tied to a place is stored as local wall time plus a zone identifier, never as an offset, because the offset for that place on that date is a prediction that can change.
3. A recurring event is stored as a rule plus a zone, and expanded at read time. Materialising future occurrences bakes in offsets that may change.

The single test question that catches most errors: if a government changes its rules next year, does the stored value still mean the same thing? An instant does for the past. An offset does not for the future.

Bundle shape, with the arithmetic. Take the artefact's 800 messages at about 60 bytes each, so roughly 48 KB per locale.

At 5 locales, splitting saves 192 KB, about 0.96 s of transfer. At 40 locales the unsplit option is 1.9 MB and the question stops being interesting. The threshold where splitting starts to pay is roughly where the saved bytes exceed the round trip cost, which by the arithmetic in Module 11 is around 30 KB, or roughly two locales' worth of messages here.

Fallback chain. Define it explicitly: requested locale, then the base language without the region, then the default. A missing message renders the fallback, and in development it should render loudly so it is caught before release.

Pseudo-localisation for layout. Generate a fake locale that expands every string by a fixed factor and adds accents, then run your visual tests against it. A 35 percent expansion is a reasonable planning figure because several European languages run substantially longer than English for short interface strings. Measure your own from delivered translations once you have them.

15d. Worked example

The prompt. "Our product ships in English only. We are launching in Germany, Poland, Japan, Saudi Arabia and Brazil in two quarters. Design the front end work."

Inputs, stated before I touch anything:

Block A. Purpose: separate the work that is per locale from the work that is once

I split the project in the first two minutes, because the two halves have completely different shapes and completely different owners.

The useful conclusion: five of the seven rows do not get more expensive with more locales. So the estimate for six locales is close to the estimate for two, and the argument for doing the once work properly is stronger than it looks.

The error most readers make here. Estimating the project as translation management. The translation vendor's work is real and it is not the engineering project. The engineering project is the 60 concatenation sites and the stylesheet.

Block B. Purpose: fix the message layer, since it constrains everything downstream

The 60 concatenation sites are the critical path, because a translator cannot start on a fragment and because Polish and Arabic make fragments unfixable.

The migration, and why in this order:

1. Introduce a message format that supports plural and selection, with one message per user visible sentence.
2. Convert the 60 concatenation sites. Each becomes one message with a placeholder and, where a count is involved, a plural selection.
3. Audit component APIs for two category assumptions: any prop pair named singular and plural, any conditional on count === 1. These are the sites that look correct in English and are unfixable by translation.
4. Add context notes to ambiguous keys before extraction, because retrofitting context after the first delivery means re-reviewing everything.

I size it: 60 sites at roughly 20 minutes each including review is about 20 hours, plus the component API audit which is the uncertain part. I would ask for a count of components accepting singular and plural props before committing.

The error most readers make here. Converting the messages and leaving the count === 1 conditionals in components. They are the same defect in a different file, and they are invisible in English, German and Portuguese while being wrong in Polish and Arabic.

Block C. Purpose: make direction a build in property rather than a variant

Arabic makes direction real. The cheap approach is to convert the stylesheet to logical properties and set dir from the locale, and the expensive approach is a mirrored stylesheet variant.

I take the first, and I state the work:

• Count declarations naming a physical side. This is a mechanical scan, and it is the estimate.
• Convert them. Most convert one for one. The ones that do not are the interesting cases: absolutely positioned decorations, transforms and shadows with a horizontal offset, and anything with a hard-coded direction in an image.
• Handle the non mirroring list from earlier: numbers, phone numbers, media timelines, charts with a time axis, logos and code. Each needs an explicit direction so it is not mirrored by the ancestor.
• Add bidi isolation around every user supplied string rendered inside a sentence: names, file names, search terms.

The result is that adding a second right to left locale later costs nothing, which is the argument for doing it this way rather than shipping a mirrored variant stylesheet.

The error most readers make here. Mirroring everything by applying a transform to the whole page. It reverses text that must not reverse, breaks images, and produces a result that is confidently wrong rather than obviously wrong, which is harder to catch in review.

Block D. Purpose: cut the bundle so 6 locales cost what 1 costs

Arithmetic from the stated inputs: 800 messages at 60 bytes is about 48 KB per locale, 6 locales is about 288 KB if bundled together, and each user needs 48 KB.

• Split one chunk per locale: the user downloads 48 KB rather than 288 KB, saving 240 KB, about 1.2 s at 200 KB/s.
• The extra round trip costs about 150 ms, so the split is clearly positive here. I check it rather than assuming it, because at 3 small locales it would not be.
• Load the locale chunk as early as possible, ideally as a preload declared in the document, since first render usually needs messages and a late request creates a waterfall.

I decline per route splitting at this size and say why: 48 KB per locale is already small relative to the application bundle, and splitting further adds navigation time round trips for a few kilobytes each, below the break even from Module 11.

The error most readers make here. Splitting by locale and then loading the chunk from application code after hydration, which puts a network round trip between first paint and readable text. The request must start with the document.

Block E. Purpose: verify layout per locale without hiring six reviewers

Three mechanisms in increasing cost, and I use all three because they catch different things.

I bound the last one explicitly: the 20 screens covering the most traffic, once per release, not the whole product. An unbounded review commitment is the thing that quietly stops happening in quarter three.

The error most readers make here. Waiting for real translations to test layout. Pseudo-localisation finds the same truncation bugs weeks earlier, with no dependency on the vendor's schedule, and it is a build configuration rather than a process.

15e. Fade the scaffold

Fade 1: a numbers heavy analytics product. Dashboards full of currency, percentages, large numbers and dates, launching in the same six locales. Same five block shape, last block blank.

• Block A, separate per locale from once work: the message layer matters less here (dashboards have few sentences) and the formatter layer matters far more. The once work is dominated by finding every place a number, currency or date is turned into a string.
• Block B, fix the layer that constrains the rest: not messages, formatters. Every formatting site must take an explicit locale, an explicit currency where relevant, and an explicit time zone. Grouping separators, decimal separators and currency placement all differ, and a hand-rolled formatter will be wrong in at least one launch locale.
• Block C, direction: less layout work than the worked example (charts and tables mostly do not mirror) and more numeric care. Numbers keep their direction inside a right to left layout, table columns of numbers should stay aligned by decimal, and axis labels need explicit direction.
• Block D, bundle: message bytes are small here, so per locale splitting saves little. The bytes that matter are locale data for formatting, and the platform already ships that, which is a strong argument against a formatting library.
• Block E, verification per locale: you write this block.

Fade 2: adding one right to left locale to an otherwise finished product. The product already handles 8 left to right locales correctly, with a proper message layer, formatters and per locale bundles. Only Hebrew is being added. Last two blocks blank.

• Block A, separate per locale from once work: almost everything per locale is already solved. The whole project is the once work triggered by having any right to left locale, which was deferred and is now due.
• Block B, fix the constraining layer: the stylesheet. Count declarations naming a physical side, and expect this count to be the schedule. In a mature product with a design system, most of these live in the design system, which is good news: fix them once and every consumer benefits.
• Block C, direction: you write this block.
• Block D, bundle: you write this block.

15f. Check yourself

Q1. A component in your library accepts singularLabel and pluralLabel props and is used in 120 places. Explain what is wrong, and design the migration.

Q2. Your team proposes shipping all 12 locales in one bundle "to avoid a round trip on first paint". Evaluate with numbers, then give the option they have not considered.

15g. When not to use this

A full message format runtime with plural and selection support.

Per locale bundle splitting.

Right to left support.

A third party formatting library for numbers and dates.

Module 16. Testing and rollout

Time: 35 to 45 minutes reading, 25 to 35 minutes practice.

Testing questions in a frontend round are rarely "do you write tests". They are "what would you test, at which level, and what would you refuse to test", and the refusal is where the signal is. Rollout is the same question one step later: how does a change reach users in a way you can stop.

16a. Predict first

Read this artefact and commit to an answer before continuing.

+---------------------------------------------------------------+
| Continuous integration suite, measured over one month:        |
|                                                               |
|   unit           4,000 tests    2 min    flake near zero      |
|   integration      600 tests    6 min    flake 0.1% per test  |
|   end to end       300 tests   34 min    flake 0.5% per test  |
|                                                               |
| Policy: any red run blocks the merge queue, rerun on red.     |
| The team opens 40 pull requests per day.                      |
+---------------------------------------------------------------+
Caption: suite sizes, durations and per test flake rates, with
the merge policy that consumes them.

Question. Compute the probability that one run is green when the code is perfect, then compute the machine time the merge queue spends per day, and say which lever fixes it fastest.

16b. What belongs at each level in a user interface

Define the levels by what they instantiate, since that is what determines their cost and their flake rate.

The mock boundary matters more than the level names. Mock at the transport boundary (the request and response) rather than at your own module boundary. A test that stubs your own data access layer passes when that layer is wrong.

Query through the accessible interface. Find elements by role and accessible name rather than by test identifier or class. Two benefits for the price of one: the test survives refactoring, and it fails when the accessible name is missing, which turns a large share of your integration suite into an accessibility assertion at no extra cost.

A useful ratio to be able to defend. For a mature interface, the shape that survives is roughly: many unit tests, a substantial integration suite that is the real safety net, and end to end tests numbering in the tens. The artefact above shows what happens when the last number reaches the hundreds.

16c. Contract testing, visual regression, accessibility checks

Contract testing verifies that the shape you mock in tests still matches what the server actually returns.

The problem it solves is mock drift: your integration tests mock a response, the server changes a field, every test still passes, and production breaks. The mock was a copy of a truth that has moved.

Pick by whether you control the provider. If you do, schema derived mocks are usually enough. If you do not, recorded fixtures with a scheduled refresh is the realistic option.

Visual regression, priced. Assume 60 components, 3 viewports, 2 themes.

• Images per run: 60 x 3 x 2 = 360
• At 20 builds per day: 7,200 renders per day, a real but affordable compute cost
• The dominant cost is human: at an assumed 2 percent of images differing for reasons unrelated to the change, 360 x 0.02 = about 7 images to review per build, every build

That 7 is the number that kills visual regression suites. Below a threshold nobody reviews them and everyone approves. Three controls, in order of value:

Accessibility in continuous integration, honestly. Automated rule sets check the machine checkable subset: missing accessible names, insufficient contrast against a computed background, invalid roles, duplicate identifiers, missing form labels. They cannot check whether the focus order makes sense, whether an error message is announced at the right moment, or whether a custom widget's interaction model matches user expectations.

So run both, and know what each is for:

The middle row is the highest value and the most neglected. A test that opens a dialog, asserts focus moved into it, presses escape, and asserts focus returned to the trigger is ten lines and catches the defect that automated rules never see.

Rollout: flags, canaries and kill switches

Three kinds of flag, with different lifetimes. Conflating them is why flag systems become unmaintainable.

Canary sizing, derived. For a two sided comparison at 5 percent significance and 80 percent power, the samples needed per arm are approximately n = 16 x variance / (effect size squared). For a rate p the variance is p x (1 - p).

Case one, detecting a 1 percentage point drop in a 20 percent conversion rate:

• variance = 0.2 x 0.8 = 0.16
• effect = 0.01, squared = 0.0001
• n = 16 x 0.16 / 0.0001 = 25,600 per arm

Case two, detecting a doubling of a 0.5 percent session error rate:

• variance = 0.005 x 0.995 = 0.004975
• effect = 0.005, squared = 0.000025
• n = 16 x 0.004975 / 0.000025 = 3,184 per arm

The conclusion that changes how you design a canary. Error rate is detectable in about 3,200 sessions per arm, which on a busy site is minutes. Conversion at one percentage point needs 25,600 per arm, which is hours, and a 0.2 point change would need 640,000 per arm.

So a canary is an error and latency detector, not a conversion detector. Gate the automatic abort on technical guardrails that move fast and loudly. Measure conversion with a proper experiment that runs long enough. Teams that gate a canary on conversion either wait too long to roll out or abort on noise.

Kill switch requirements, which are more specific than they sound.

16d. Worked example

The prompt. "We rewrote the checkout form. It is the highest value flow in the product. Design the testing and rollout plan."

Inputs, stated before I touch anything:

Block A. Purpose: decide what must be true before any of this reaches a user

I start from the failure I am most afraid of, not from a test pyramid diagram. For checkout that is: a user can enter valid details and cannot complete the purchase, and we do not find out for hours.

That fear implies three requirements, and everything else follows from them:

Saying this first reframes the answer from a list of test types into a design with a stated objective, which is the difference between a mid and a senior answer to this exact prompt.

The error most readers make here. Opening with the test pyramid. The pyramid is a means. Starting from the feared failure produces a plan you can defend and also produces the test selection for free.

Block B. Purpose: put each assertion at the cheapest level that can hold it

I go through the flow and assign each behaviour to a level, with a reason.

Two end to end tests, not twenty. From the opening arithmetic, 2 tests at 0.5 percent flake pass together with probability 0.995^2 = 0.990, so the suite is a signal rather than a lottery.

I also state what I deliberately do not test end to end: every validation rule, every error message, every country's postcode format. Those are asserted one or two levels down where they are fast and deterministic.

The error most readers make here. Adding end to end coverage in proportion to how important the flow is. Importance argues for more assertions, not for more assertions at the most expensive and least reliable level.

Block C. Purpose: stop the mocks from drifting away from the server

Every integration test in Block B mocks the payment and address services. That mock is a copy of a contract that will change.

• The payment provider is third party, so consumer driven contracts are not available. I use recorded fixtures from their sandbox, refreshed nightly by a scheduled job that fails loudly when a response shape changes.
• Our own order service is ours, so mocks are generated from its published schema, and a schema change breaks the consumer build immediately.
• One end to end test against the sandbox is the final backstop, which is a second reason the two end to end tests earn their place.

I name the failure this prevents, because it is specific: the provider adds a required field, our mocks keep the old shape, every test passes, and checkout fails in production for exactly the users whose payment path hits the new requirement.

The error most readers make here. Treating mock drift as a testing detail. It is the mechanism by which a green suite becomes uninformative, and it fails silently, which makes it worse than a flaky test.

Block D. Purpose: design the exposure ramp and its abort rule

I use the sizing arithmetic to pick the ramp rather than picking round numbers.

• Session error rate baseline 0.5 percent. Detecting a doubling needs about 3,184 sessions per arm.
• At 120,000 checkout sessions per day, a 5 percent canary gets 6,000 sessions per day, so about 250 per hour. Reaching 3,184 takes roughly 13 hours.
• That is too slow for the "detectable in minutes" requirement, so I start the ramp higher: 25 percent gives 1,250 sessions per hour and reaches the threshold in about 2.5 hours.
• For faster detection I add a much larger effect guardrail: a checkout specific error rate that would rise from near zero to a large fraction if the form is broken. A change from 0.5 percent to 10 percent needs 16 x 0.005 x 0.995 / (0.095 squared) = 16 x 0.004975 / 0.009025 = about 9 sessions per arm, so a catastrophic break is visible almost immediately.

The ramp: 5 percent for 1 hour as a smoke check, 25 percent for 3 hours, 50 percent overnight, 100 percent the next morning. Abort automatically on the catastrophic guardrail, page a human on the doubling guardrail.

Conversion is measured, and it is not a gate. From the arithmetic, one percentage point needs 25,600 sessions per arm, about 10 hours at 25 percent exposure, so it informs the decision to stay at 100 percent rather than gating the ramp.

The error most readers make here. Picking 1 percent, 5 percent, 25 percent, 100 percent because those are the conventional numbers. The exposure percentage should come from how long you are willing to wait for the guardrail to become readable, which is arithmetic.

Block E. Purpose: make the reversal faster than the diagnosis

A rollback redeploys. A kill switch does not. For the highest value flow in the product I want the second.

The cost of this is that both code paths ship during the ramp, which adds bytes. I price it and accept it: if the new form is 30 KB compressed, carrying both for a week costs about 0.15 s of transfer at 200 KB/s for that week. That is a cheap insurance premium on the highest value flow in the product.

The error most readers make here. Deleting the old code path in the same release that introduces the new one, which converts a 60 second reversal into a deploy cycle, on the day you least want one.

16e. Fade the scaffold

Fade 1: rolling out a design system major to 6 consuming applications. The change is visual and API breaking, a codemod exists, and each app has its own release train. Same five block shape, last block blank.

• Block A, the feared failure: not an outage. It is a visual regression that reaches users in one app and is attributed to the design system a week later, after five other apps have adopted. The requirement is attribution, not reversal.
• Block B, assertions at the cheapest level: unit tests for the changed component APIs, integration tests for the interaction models that changed, and visual regression as the primary signal, since the change is visual. End to end tests are close to useless here and should not be added.
• Block C, stop the drift: the equivalent of contract testing is running the consumers' visual regression suites against the release candidate before it ships, which turns consumer breakage into a pre-release signal.
• Block D, the exposure ramp: there is no percentage ramp, because adoption is per application. The ramp is ordinal: one low risk consumer first, then two, then the rest, with a defined wait between them.
• Block E, make reversal fast: you write this block.

Fade 2: an internal admin tool. 40 staff users, no revenue path, one team, weekly releases, and the team currently has no tests at all and is asking where to start. Last two blocks blank.

• Block A, the feared failure: a member of staff performs a destructive action (bulk delete, refund, permission change) on the wrong records, and there is no undo. Slowness and visual defects are annoyances here, not risks.
• Block B, assertions at the cheapest level: start with unit tests for the destructive operations' preconditions and integration tests for the confirmation interactions. Do not start with a test pyramid, start with the three operations that cannot be undone.
• Block C, stop the drift: you write this block.
• Block D, the exposure ramp: you write this block.

16f. Check yourself

Q1. Your team wants an end to end test for every user story, arguing that it is the only level that tests what the user actually experiences. Respond with arithmetic and then with a concession.

Q2. A canary at 1 percent exposure has been running for 6 hours on a site with 40,000 daily sessions. Conversion is down 0.8 percentage points from a 15 percent baseline. Should you roll back?

16g. When not to use this

End to end tests beyond a small set.

Visual regression testing.

Consumer driven contract testing.

A percentage based canary with an automatic abort.

Module 17. Observability

Time: 30 to 40 minutes reading, 20 to 30 minutes practice.

Observability is where a frontend design answer either becomes operable or stays theoretical. The organising question: when a user says the page is slow or broken, what exactly do you look at, and does it contain enough data to answer.

17a. Predict first

Read this artefact and commit to an answer before continuing.

+---------------------------------------------------------------+
| Real user monitoring, as configured:                          |
|   head sampling      1% of sessions                           |
|   page views per day 2,000,000                                |
|   dashboard cells    30 routes x 4 device classes = 120       |
|   errors             sampled at the same 1%                   |
|                                                               |
| Dashboard reads: LCP p75 = 2.1 s, labelled good.              |
| Support queue: 40 tickets this week reporting slowness.       |
+---------------------------------------------------------------+
Caption: a sampling configuration, the dashboard it produces,
and the contradicting evidence from support.

Question. Compute the samples per dashboard cell and say what the dashboard can and cannot support. Then name the single configuration change with the largest effect.

17b. What to collect, and why attribution is the whole game

A vitals number on its own tells you something changed. It never tells you what to do. The payload alongside it does.

Route pattern, not raw URL. Collecting the raw path creates unbounded cardinality and makes every cell too small to read, which is exactly the failure in the opening artefact. Collect the pattern, and keep the raw path only on error records where volume is low.

Build identifier on every sample. It is the cheapest field on the list and it is what turns "performance got worse this week" into "performance got worse in build 4471". Without it, correlating a regression to a deploy is manual and usually wrong.

17c. Sampling that leaves the data readable

Three strategies, and the third is the one that rarely appears in an answer at all.

Sizing stratification, worked. Target roughly 1,000 samples per cell per day, which by the arithmetic in Module 11 gives a p75 stable to about 2.7 percentile points.

• A route with 500,000 daily views needs a 0.2 percent rate to reach 1,000
• A route with 5,000 daily views needs 20 percent
• A route with 800 daily views cannot reach 1,000 at any rate, so aggregate it into an "other" bucket and stop pretending it has its own number

That last line is the discipline. A dashboard cell that cannot be readable should not exist, because an unreadable cell is worse than an absent one: someone will act on it.

Always collect at 100 percent. Errors, and any event rare enough that sampling changes the answer. The cost is low precisely because they are rare.

Errors, boundaries and the noise you did not cause

Error boundaries catch less than people assume. State the gaps, because "we will add error boundaries" is a common and incomplete answer.

So a complete answer pairs boundaries with a global handler for uncaught errors and one for unhandled promise rejections, and it places boundaries deliberately: one per route, one per independently failing widget, and not one per component, which produces a page of fallbacks and hides the failure.

The noise sources, which are most of your error volume.

Without filtering, the noise categories dominate and the tracker becomes ignorable, which is the actual failure mode: the data is present and nobody reads it.

Chunk load failures, and the retention arithmetic. After a deploy, a client holding the old document requests an asset that no longer exists.

Price keeping old assets:

• Assume 400 chunks per build at an average 30 KB, so about 12 MB per build
• 20 builds per day for 30 days is 600 builds, about 7.2 GB total

Storage of a few gigabytes is not a meaningful cost, so retention is a policy choice rather than a budget question. Keep 30 days of build assets.

Then add the client side half, because retention alone does not cover a tab open for months:

• On a chunk load error, reload the page once, guarded by a marker so it cannot loop
• If the marker is already set, show an explicit "a new version is available" message rather than reloading again
• Emit a distinct event for this case so it does not pollute the general error rate

Source maps and session replay

Source maps in production, three options.

Two notes worth stating. First, minified code is not a security control, so withholding maps protects intellectual property and convenience, not safety. Second, whichever you choose, the map must be keyed to the build identifier or symbolication silently produces wrong line numbers after the next deploy.

Session replay, and its real price. Replay reconstructs a session by recording document mutations and input events, then replaying them.

Cost, computed:

• Assume 60 KB per minute of compressed mutation data for a moderately dynamic interface, and a 6 minute average session, so about 360 KB per recorded session
• 2,000,000 page views per day at 3 views per session is about 667,000 sessions
• At 1 percent recording that is 6,670 sessions, about 2.4 GB per day, roughly 72 GB per month before retention policy

Plus a device cost that rarely gets mentioned: continuously observing document mutations is main thread work on the user's device, so a replay tool can degrade the interaction metric you installed it to investigate. Measure your own interaction metric with the tool on and off before deciding.

The privacy cost, stated as a design rule. Replay records what is on screen, which in most products includes personal data.

17d. Worked example

The prompt. "We are launching a checkout funnel. Design the observability so that when it breaks at 2 am, the person on call can tell what broke and for whom."

Inputs, stated before I touch anything:

Block A. Purpose: write the questions the data has to answer, before choosing tools

I list the questions the person on call will actually ask, because each one implies a field or a signal, and any question I cannot answer is a gap I would rather find now.

The last row is the one that catches people. An error count rises when traffic rises. On call needs errors per session, and the denominator must be collected with the same sampling as the numerator or the ratio is meaningless.

The error most readers make here. Choosing tools first. The tool list is short and mostly interchangeable. The field list is the design, and it is what makes any tool useful.

Block B. Purpose: set sampling so every cell is readable or absent

Cells I want: 4 funnel steps x 3 device classes = 12 cells. That is a deliberately small number, chosen because the funnel is one route family rather than the whole site.

• Target 1,000 samples per cell per day, from the Module 11 arithmetic, giving a p75 stable to about 2.7 percentile points
• 12 cells x 1,000 = 12,000 samples per day needed
• 120,000 sessions produce roughly 4 step views each, so about 480,000 step views per day
• Required rate: 12,000 / 480,000 = 2.5 percent

I round to 5 percent for headroom on the smallest device class, which is typically much smaller than the largest. Then I check the smallest cell rather than the average: if the least common device class is 10 percent of traffic, its cells get 480,000 x 0.10 x 0.05 / 4 = 600 samples, which is below target, so I stratify and raise the rate for that class to 10 percent with a recorded weight.

Errors and funnel step transitions are collected at 100 percent, because they are rare and because the denominator must be exact.

The error most readers make here. Setting one sampling rate for everything. Timing data is high volume and tolerates sampling. Errors and conversion events are low volume and do not.

Block C. Purpose: place error handling so a failure is contained and named

Three layers, each catching what the others cannot:

Plus the filtering rules from earlier, applied at ingestion rather than at query time, so the dashboards are clean by default: extension frames, injected script signatures, bot user agents, and chunk load failures routed to their own event type.

I place a boundary around the payment element specifically because it is third party code whose failure I cannot fix at 2 am. The fallback for that boundary matters: it must let the user complete by another route if one exists, or tell them clearly if not, because a silent empty region is the worst outcome.

The error most readers make here. A boundary per component. It converts one visible failure into a page of small fallbacks, none of which is alarming enough to be reported, and the aggregate looks like a working page.

Block D. Purpose: decide on replay by pricing it against the alternative

Replay is the expensive item, so I price it and then price the cheaper thing.

• 120,000 sessions per day, recording 1 percent is 1,200 sessions at 360 KB, so about 430 MB per day, about 13 GB per month before retention. Affordable
• The device cost is the real question: I would measure the funnel's interaction metric with recording on and off before enabling it, because degrading checkout interactivity to observe checkout interactivity is a bad trade

The cheaper alternative I compare against: a breadcrumb trail attached to every error, recording the last 20 user actions, the last 10 network requests with status and duration, the funnel step history, and the state of any feature flags. That is a few kilobytes per error, sent only with errors, with no continuous observation cost and a far smaller privacy surface.

My choice: breadcrumbs for everyone, and replay enabled only for sessions that have already errored, if the tool supports retroactive capture, or for a small opt in population. This is tail sampling applied to replay, and it captures most of the value at a fraction of the cost.

Masking is default deny, payment and authentication fields are never recorded under any configuration, retention is set in days, and access to recordings is logged.

The error most readers make here. Enabling replay at a high rate on the most sensitive flow in the product, because that is where the debugging value seems highest. It is also where the privacy exposure is highest, and the two scale together.

Block E. Purpose: define what wakes someone up, and what does not

Alerting rules, each with the reason for its threshold:

The last row is a policy statement and it belongs in the design: performance degrades, it does not break. Paging on a percentile trains people to ignore pages.

The error most readers make here. Alerting on absolute counts. A count alert fires every peak hour and stays silent during an overnight outage, which is precisely inverted from what you want.

17e. Fade the scaffold

Fade 1: an internal admin tool. 40 staff users, 1,500 page views per day, one team, and the tool performs destructive operations. Same five block shape, last block blank.

• Block A, the questions to answer: mostly "what did this specific person do before it broke", not "which segment is affected". With 40 users, individual identification is both possible and appropriate, which changes the design more than any tooling choice.
• Block B, sampling: collect everything at 100 percent. 1,500 page views per day is a rounding error in any monitoring budget, and any sampling makes the data unusable for the individual level questions in Block A.
• Block C, error handling: one boundary per route is enough. Global handlers matter more here than boundaries, because a small tool has more ad hoc event handler code and fewer render paths.
• Block D, replay versus breadcrumbs: replay is genuinely attractive at this scale because the volume is tiny and the users are colleagues who can be told they are recorded. The privacy analysis is different, not absent: staff are still people, and the tool shows customer data, so masking rules still apply to the content on screen even when the user consents.
• Block E, what wakes someone up: you write this block.

Fade 2: a marketing site. 500,000 page views per day, largely anonymous first time visitors, three third party tags, no login, no funnel beyond a newsletter form. Last two blocks blank.

• Block A, the questions to answer: the dominant question is "did a marketing change break or slow the page", and the secondary one is "which third party is responsible". The site's own code changes rarely and the tags change weekly.
• Block B, sampling: 500,000 views per day at 10 percent gives 50,000 samples. With 8 landing pages and 3 device classes, 24 cells get about 2,000 each, which is above the 1,000 target. Errors at 100 percent as always.
• Block C, error handling: you write this block.
• Block D, replay versus breadcrumbs: you write this block.

17f. Check yourself

Q1. Your error dashboard shows 40,000 errors per day and the team has stopped looking at it. Give a plan to make it useful again, in order.

Q2. A product manager asks for session replay on 100 percent of sessions "so we never miss anything". Give the cost in numbers and a counter proposal.

17g. When not to use this

Session replay.

A full real user monitoring pipeline with per segment dashboards.

An error boundary at every component.

Publishing source maps publicly.

Module 18. Level calibration

Time: 25 to 35 minutes reading, 20 to 30 minutes practice.

The same prompt is asked at every level, and the difference is not how much you know. This module makes the difference explicit so you can hear it in your own answers.

18a. Predict first

Read this artefact and commit to an answer before continuing.

+---------------------------------------------------------------+
| Prompt: design the front end for a live order tracking page.  |
| Sub question: how does the driver location reach the page?    |
|                                                               |
| ANSWER 1  Use WebSockets. The server pushes coordinates and   |
|           we move the marker. It is real time.                |
|                                                               |
| ANSWER 2  Roughly one small message every few seconds per     |
|           active order, and the client writes almost nothing, |
|           so I would take server sent events plus POST. I     |
|           would size the heartbeat from the shortest idle     |
|           timeout in the path and use full jitter on          |
|           reconnect so a deploy does not make a herd.         |
|                                                               |
| ANSWER 3  First, who owns the location feed and what is its   |
|           update rate and freshness target? If it is an       |
|           existing service, the front end question is mostly  |
|           degradation and cost. I would make the page correct |
|           with a polling fallback first, because that decides |
|           whether push is a dependency or an enhancement, and |
|           it decides what the sessions that never connect     |
|           see. Then I would pick a transport, and name the    |
|           measurement that would make me revisit it.          |
+---------------------------------------------------------------+
Caption: three answers to one sub question, unlabelled.

Question. Rank them by level, then state the specific thing each higher answer added, in one clause each.

18b. What each level adds, dimension by dimension

The single sentence version. Mid demonstrates knowledge, senior demonstrates judgement under constraints, staff demonstrates judgement about which problem to solve.

What does not raise your level, despite feeling like it does.

18c. The negative signals, by level

Interviewers calibrate down on specific things, and they are different at each level.

The last row is the one that surprises people. Reframing is a staff move only when it is followed by a concrete design. Reframing alone reads as avoidance, and it is a common failure mode for candidates who have read about seniority rather than practised it.

18d. Worked example

The prompt. "Design the front end for a live order tracking page. Users open it after ordering and watch until delivery."

I will answer the same prompt three times, one level per block, at the same length, so the difference is visible as content rather than as volume.

Inputs, shared by all three:

Block A. Purpose: show the mid level answer in full, so its ceiling is visible

"I would build a page showing a map with the driver's position, the order status steps, and an estimated arrival time. I would use WebSockets so the position updates live. The map is a third party component. State lives in a store, and I would show a loading state while the first data arrives and an error state if the request fails.

For performance I would code split the map since it is large, and lazy load it. For accessibility I would make sure the status steps are readable by a screen reader, since a map is not accessible on its own."

What is right about this: it is a complete, working design with no errors in it. The map splitting instinct is correct. Noticing that a map is not accessible is better than most answers give.

What sets its ceiling: every choice is asserted. WebSocket is chosen without a count, code splitting without a size, and the accessibility point stops at "readable" without saying what a screen reader user actually needs from a live tracking page.

The error most readers make here. Believing this answer is weak. It is not weak, it is unfalsifiable. The interviewer has nothing to probe except by asking "why", and the candidate's answer to "why" is what actually determines the level.

Block B. Purpose: show what the senior answer adds, and where it adds it

"Let me size it before choosing. 80,000 concurrent sessions, one update every 5 seconds, so 16,000 messages per second outbound to clients. Clients send almost nothing: a page view and maybe a support tap.

That read to write ratio, several thousand to one, points at server sent events rather than WebSocket. WebSocket would cost me reconnect code I have to write myself and middlebox incompatibility, and buys duplex I do not need. I would move to WebSocket if the product added driver chat, which would change the write rate by orders of magnitude.

Reconnection: immediate first retry, then full jitter capped at 30 seconds. With 80,000 clients and a deploy, an uncapped fixed retry would put 80,000 connection attempts into one second against a fleet that accepts a few thousand.

Budgets: the map component is the biggest byte item, so I would lazy load it behind the initial paint and render order status from server rendered markup first, since status is what the user checks most often and it does not need the map. I would set a byte budget on the route entry and enforce it in the build.

Accessibility: the map is decorative for this purpose. The authoritative content is the status and the estimate, which I would put in a live region that announces on change but not on every position update, since announcing a coordinate every 5 seconds is hostile."

What this added: a count that drove the transport choice, the condition that would reverse it, an operational consequence, a byte decision tied to what users look at, and an accessibility decision that is specific rather than aspirational.

The error most readers make here. Adding numbers that do not eliminate anything. Every number above rules out an option. A number that does not is decoration, and interviewers notice the difference.

Block C. Purpose: show what the staff answer adds beyond the senior one

"Before transport, two questions that change the design. Who owns the location feed, and what is its actual freshness? If it updates every 5 seconds and is already smoothed, my job is presentation and degradation. If it is raw and jittery, I own interpolation and the perceived quality of the whole feature.

Second: what does the user actually want from this page? My assumption is reassurance, not coordinates. If that is right, then the arrival estimate and the status are the product, and the moving marker is supporting evidence. That reorders everything: the estimate must be correct and stable, and the map can be late, degraded or absent.

So I design the page to be correct with a 30 second polling fallback first. About 3 percent of sessions never establish a socket, and on a page whose purpose is reassurance, 3 percent of users seeing a frozen map is worse than 100 percent seeing a slightly stale one. Push becomes an enhancement over a correct baseline, which also means a push outage is a degradation rather than an incident.

Then transport, and the senior reasoning applies: read heavy, so server sent events, with the write rate as the condition that would change it.

One organisational point: the estimate is computed by another team's service. Its accuracy determines the perceived quality of my page, and I will be the one receiving the complaints. I would agree an accuracy target and a way to display uncertainty, because showing a confident wrong time is worse than showing a range.

What I would measure first: the share of sessions that never receive an update within 10 seconds of load, by network class. That single number tells me whether the fallback is carrying 3 percent or 15 percent of traffic, and it decides where the next quarter of work goes."

What this added: a reframing that changed the design (fallback first), an assumption about user intent stated as an assumption, a cross team dependency owned rather than mentioned, and a first measurement that would direct future work.

The error most readers make here. Delivering the staff framing and stopping there. Notice that the answer above still lands on a transport, a fallback interval, a percentage and a metric. Reframing without landing reads as evasion, and it calibrates down, not up.

18e. Fade the scaffold

Fade 1: an internal admin console for support staff. The prompt is "design the front end for the tool support agents use while on a call with a customer". Same three block shape, last block blank.

• Block A, the mid answer: a search box, a customer detail view with tabs for orders, payments and notes, an action panel for refunds and account changes. Client side routing, a data fetching layer with caching, loading and error states, and a design system for consistency. Complete, correct, unfalsifiable.
• Block B, the senior answer, the budget: agents handle calls back to back, so the binding constraint is time to first useful data during a live call, not bundle bytes on a fast internal network.
• Block B, the senior answer, the moves that follow: prefetch the customer record from the telephony system's incoming call event before the agent opens anything, which removes a full round trip from the start of every call. Keyboard first design, since agents type while talking. Optimistic updates rejected for refunds, because a rolled back refund shown to an agent who has already told the customer is worse than a 400 ms wait.
• Block C, the staff answer: you write this block.

Fade 2: a component scale prompt. "Design a date range picker for a booking product." Last two blocks blank.

• Block A, the mid answer: two linked calendar months, a start and end selection, disabled dates for unavailable ranges, keyboard navigation with arrow keys, and a controlled value with an onChange callback. Localised month names. Complete and correct as far as it goes.
• Block B, the senior answer: you write this block.
• Block C, the staff answer: you write this block.

18f. Check yourself

Q1. You are interviewing at senior level. In the last ten minutes the interviewer asks about rolling the design out across three teams. You have not finished the deep dive you started. What do you do, and why?

Q2. A candidate opens with "before I design anything, I have five questions", asks all five, receives the answers, and then produces a design that would have been identical regardless of any of them. What level does this read as, and why?

18g. When not to use this

Answering above your level.

Opening with a reframing of the prompt.

The level delta as a preparation tool.

Case study 1: News feed application

Four assumptions run through every case study on this page. They exist so that every latency, byte and memory claim below is arithmetic you can redo with your own measurements instead of a number you have to trust.

Say all four out loud in the room. A number offered as a placeholder you will measure reads as engineering. The same number stated as fact reads as recall.

The prompt (news feed)

"Design the front end of a news feed: an infinite list of posts that a user scrolls, likes and comments on."

Questions that fork the design (news feed)