Katkat
Back

Design a Fast Product Search Page: Search Input over an Unbounded Catalog Grid

AtlassianFrontend Engineer · Technical Screen
HardFrontend EngineerTechnical ScreenSystem Design

Last updated

A front-end system design question about a product search page with a search input above a grid of results drawn from a catalog of unbounded size. It probes the component tree, where search state should live, and how the candidate keeps typing responsive and results fast when the result set can never be loaded all at once.

Design the front end of a product search page. A search input sits at the top, and below it a grid shows the product catalog. When the user types a search term, the grid should show the matching (filtered) products. The catalog has no upper bound on size, so a query can match an unlimited number of products.

The interviewer wants two things: the structure of your component tree, and how you make sure results come back quickly after the user types a search term. In the reported interview this was a short discussion of about 10 minutes following a coding exercise, so lead with the decisions that matter most.

Constraints and Clarifications

  • The catalog cannot be assumed to fit in the browser; the client can only ever hold a slice of the results.
  • What each card shows, how many cards fit in a row, and what the backend search API offers were not reported. Ask, or state your assumptions.

Clarifying Questions

  • Should results update as the user types, or only when they submit the search?
  • Does a search API already exist? Does it support paging, sorting and a total count, or do we define its contract?
  • What does each product card show (for example image, name and price), and how many cards fit in a row?
  • Infinite scroll or numbered pages? Should the query live in the URL so results can be shared and survive the Back button?
  • Which devices and network conditions matter most?

Part 1 — Component tree and state

Lay out the components, what each one owns, and how the search term and the results flow between them.

What This Part Should Cover

  • A component hierarchy with clear responsibilities: input, results container, grid, card and status views
  • Where the query, results, paging position and request status live, and how they flow
  • Loading, empty and error presentation that does not shift the layout
  • Keeping the query in sync with the URL

Part 2 — Fast results for an unbounded catalog

How do you make sure the grid shows the right results quickly after the user types, when the result set can be arbitrarily large?

Clarifying Questions for this Part

  • What does "fast" mean here: time until the first results appear, or time until the grid is complete and stable?
  • Can results for a query be cached, or does the catalog change too often for that?

What This Part Should Cover

  • Controlling request volume and discarding stale responses
  • Caching and reusing results across repeated or refined queries
  • Paging through the result set and limiting rendering cost (DOM size, images)
  • What the backend must provide for fast search over a very large catalog

Hints

Hint 1

Decide who owns the query: The input, the request logic and the grid all depend on the search term. Place that state where everything that needs it can reach it, and ask whether every keystroke should re-render the whole grid.

Hint 2

Not every keystroke needs a request: Count how many requests a fast typist would trigger, and ask which of those responses the user actually needs to see, including what happens when they come back out of order.

Hint 3

Unbounded means never everything at once: Think about how much of the result set a user can see at one time, both in what you fetch and in how many cards you put in the DOM.

Follow-up questions

  • The user types "lap", then quickly "laptop", and the response for "lap" arrives last. What does your grid show, and how do you guarantee it is correct?
  • A user scrolls deep into the results, opens a product, then presses Back. How do you restore where they were?
  • How would you measure whether search feels fast for real users?
  • If the catalog were only a few hundred products, what would you design differently?