Frontend System Design Interview Walkthrough: Build Google Search

THE CONCEPTS

The mental models, one by one

1. 01

   Dig Into Requirements Before Solving

   Functional requirements: an input, a search button (mandatory on mobile — hitting enter is hard there), a suggestion list.

   Non-functional: who are the users? How much accessibility — a government or finance client means AA/AAA, most companies don't. Internationalization? Browser support?

   Don't jump to debouncing and caching in the first minute. Mentioning solutions too early reads as assuming too much.

   Functional requirementsAccessibility levelsScoping
2. 02

   The Four-Step Structure

   Components → state → state mutations → styling. Write it down as you go.

   At the end, zoom out, screenshot the board and email it after the call. When the interviewer hangs up, every other candidate left them nothing — you left an artifact of structured thinking.

   Interview structureLeaving artifacts
3. 03

   Components & Essential State

   Components: a reusable input (with typing listeners), a search button (label + onClick props), a suggestion list.

   State: the search query, the suggestions array, and the network trio — loading, error, data. State comes from user interactions and network calls; 99% of the time, nothing else.

   Component structureEssential stateLoading / error / data
4. 04

   State Mutations & Debouncing

   On every keystroke: update the query, fetch suggestions. Untamed, a fast typist DDoSes your own backend.

   Debounce the handler: fire only after ~300ms of silence since the last keystroke. Throttling is the sibling — one call per interval regardless — better for streams, worse for typing.

   Tune the interval: debounce three seconds and users think there are no suggestions at all.

   DebouncingThrottlingEvent handlers
5. 05

   The Suggestion Data Structure

   A suggestion isn't a string. It's an object: a unique id (your stable React key — never the array index), the text, and an order field for consistent ranking.

   Expect the follow-ups: why the id? why not rely on array order? Have the re-rendering answer ready.

   Stable keysData modelingAPI shape
6. 06

   Accessibility: The 80/20

   Semantic HTML first: real input, button, ul/li — not divs with click handlers. ARIA labels only where semantics can't reach.

   Then the tab order: input → suggestions → search button, matching the visual flow, so keyboard users can drive the whole thing. Cover this and you're ahead of most candidates.

   Semantic HTMLARIATab order
7. 07

   Performance & Caching Strategy

   Of the three performance pillars, responsiveness matters most here: debounce interval + memoized list rendering with stable keys keeps INP healthy.

   Caching has layers: most-recent searches in the browser (private cache), most-frequent searches for all users at application level (Redis, or even the CDN — suggestions are just small objects).

   Know your cache eviction answer: least-recently-used beats least-frequently-used when trends die.

   INPPrivate vs shared cacheCache evictionRedis