Problem Statement: Sub-Second Search Over a Living Catalog
Frames product search as four coupled systems—retrieval, ranking, freshness, and suggestion—rather than one database query.
Problem statement
Design a product search platform that serves millions of SKUs with full-text search over titles, brands, categories, and structured attributes; typeahead autocomplete with brand and category hints; faceted navigation such as price-range, brand, color, and rating filters; typo tolerance and synonyms; and relevance ranking that blends textual match with popularity, recency, and commercial signals. Every shopper-facing path must respond in well under one second under heavy load, while the catalog underneath changes constantly: prices move, stock flips, sellers relist, and merchandisers run promotions.
This is not SELECT * FROM products WHERE title LIKE '%phone%'. A LIKE scan dies at millions of rows, cannot rank, cannot facet, cannot tolerate typos, and cannot answer in tens of milliseconds. A credible design is an information-retrieval system: an inverted index built from analyzed text, a scoring function, a facet engine over columnar doc values, a suggestion structure optimized for prefixes, and an indexing pipeline that keeps all of it nearly current without blocking queries.
Why the problem is distinctive
A product catalog is a living dataset with two conflicting properties. First, it is huge and read-heavy: hundreds of millions of documents and thousands of queries per second, dominated by repeats of popular queries and prefixes. Second, its most commercially sensitive fields—price and stock—change at rates far above the rest of the document, and serving a price that is wrong by minutes can create cart mismatches and support incidents. The architecture must therefore separate slow-changing textual content from fast-changing commercial state, and decide explicitly how stale each may be.
The second distinctive property is that correctness here is not boolean. Search has no single right answer; it has recall (did we find the products the shopper meant?), precision and ordering (are the best ones first?), latency (did we answer before the shopper abandons?), and freshness (is price and stock current?). A strong interview answer names these four axes and states that they are traded against each other deliberately.
The four planes
- Query plane: query understanding, spelling correction, synonyms, filters, and fan-out to index shards.
- Index plane: inverted index, doc values for facets and sorting, suggestion structures, and scoring.
- Ingestion plane: catalog change capture, transformation, versioned writes, and near real-time refresh.
- Signals plane: clicks, conversions, merchandising rules, and ranking features feeding models.
Keeping these planes separate is what makes the system operable. The index plane can be degraded and cached without breaking ingestion. A bad ranking model can be rolled back without reindexing. A synonym file can ship without touching the query plane code.
Key Highlights
- •Product search is retrieval plus ranking plus freshness plus suggestion, not one SQL query.
- •LIKE scans fail on scale, ranking, facets, typos, and latency simultaneously.
- •Price and stock churn far faster than text; separate slow and fast fields with explicit staleness budgets.
- •Correctness is measured in recall, ordering, latency, and freshness, not pass/fail.
- •Four planes—query, index, ingestion, signals—fail and evolve independently.
Section Rescue Kit
Buzzwords to use:
Safe statements:
- "Let me define the four quality axes before choosing any storage engine."
- "I will separate slow-changing text from fast-changing commercial state, because they need different indexing paths."