30% offEnding soon
FSD-048Frontend system design Premium

Design an E-commerce Product Search Experience

Design a fast, accessible product listing with canonical facets, stable ranking, responsive media, and separately fresh price and inventory facts.

Advanced 70 min read

A product listing is two coordinated projections. One receipt owns product identity, order, and facets. Separately versioned offer facts own price, promotion, and availability. Mixing those clocks produces stale prices, jumping cards, broken filters, and carts that disagree with the shelf.

A grid of cards looks simple because shoppers already understand the surface. The engineering underneath is less forgiving. A shopper may choose two facets, switch a card from blue to black, open a product detail page, return to the same shoe, and see its promotion expire while a slower request from the old query is still arriving.

The frontend must preserve a coherent shelf without pretending that commercial facts never change.

Clarify the commerce model before drawing cards

Ask whether the catalog is first-party, marketplace, or mixed; whether one product has many variants or sellers; which prices include tax; how inventory is represented; whether promotions are personalized; and whether search order may react to live availability. Clarify guest versus signed-in behavior, supported currencies and locales, pagination, SEO requirements, and the freshness promise shown to shoppers.

Set budgets for first useful products, product-image bytes, mounted cards and controls, filter response time, offer-event delay, stale-listing rejection, back-navigation restoration, and cart validation. “Fast shopping” is not a testable target.

The public interview prompt

Design a responsive e-commerce product-search and listing experience that supports query autocomplete handoff, canonical facets, sorting, pagination, product variants, changing prices and inventory, accessible controls, responsive images, caching, analytics, and degraded states.

Explain:

  • draft query, committed URL state, listing receipts, catalog epochs, and stale-response guards;
  • the boundary between retrieval/ranking, catalog projection, offer services, and browser interaction;
  • product, variant, offer, promotion, seller, price, and inventory identity;
  • filter counts, sort changes, cursor invalidation, pagination, and return restoration;
  • image priority, responsive candidates, layout stability, and bounded card rendering;
  • loading, empty, partial, offline, out-of-stock, repriced, and checkout-conflict states;
  • landmarks, semantic controls, focus, announcements, touch targets, and localization;
  • caching, privacy, security, telemetry, experimentation, testing, observability, and rollout.

What the premium solution covers

The full solution separates the ranked product shelf from the changing offer layer. It follows a canonical query through a merchandising loom, opens a product/variant/offer nesting tray, prints facet state on a durable receipt, inspects commercial freshness on a retail price tag, and provides a deterministic lab for transfer, DOM, latency, revision, and offer-churn pressure.

Premium solution

Continue with the complete system design

Unlock the architecture, state machine, API contracts, original diagrams, positioning model, accessibility decisions, performance budgets, testing plan, rollout strategy, scoring rubric, and interview walkthrough.

  • Detailed, beginner-friendly explanation
  • Production failure modes and trade-offs
  • Mobile-friendly architecture diagrams
  • Senior and staff-level interview signals
Unlock Premium

Frequently asked questions

What is the main frontend invariant for product search?
Only the current canonical listing receipt may publish product order and facet counts. Price and inventory are separately versioned facts and may refresh without silently changing that accepted order.
Should price and inventory live inside the cached search response?
A listing can include display snapshots, but the frontend should preserve their version and freshness metadata. Cart and checkout must validate authoritative offers again instead of trusting an old listing card.
Should selecting a color create a new search request?
A product-card variant choice is usually local card state, while a color facet changes the whole result set and belongs in the canonical URL. The product contract must distinguish those two actions.
How should product filters work with browser history?
Commit meaningful filter and sort changes to a canonical URL, reset invalid pagination, and restore the result anchor on back navigation. Draft typing and an open filter drawer are transient state.
Is infinite scrolling the best product-listing pattern?
Not by default. Numbered pages, load more, and cursor windows can all work, but the design must provide durable state, bounded DOM size, footer access, and reliable return-to-product restoration.
How should out-of-stock products update?
Apply an offer or inventory event only when its product, variant, scope, and revision match. Preserve the card anchor, announce meaningful availability changes, and issue a new listing receipt if policy changes ranking or membership.