Problem Statement & Context
What we are building and why it matters
Problem Statement & Context
A product search engine powers the discovery and conversion layer of commerce — it turns messy intent ("red running shoes size 9") into relevant products in milliseconds. Great search drives revenue; slow or inaccurate search directly causes drop-offs.
What it must handle
Massive catalogs (100M+ SKUs); high query concurrency (campaign spikes); relevance + personalization (ranking + reranking); filters and facets (brand, price, size, availability); near-real-time indexing (new products, price changes).
The journeys
- Buyer: type → autocomplete → submit → ranked results → apply filters (instant) → re-sort (rerank).
- Merchandiser: update product data → trigger re-indexing → validate ranking + filters.
The load-bearing idea: two pipelines, one index
Search is really two systems decoupled by the inverted index: a query pipeline that must be ultra-low-latency and read-heavy, and an indexing pipeline that is asynchronous and can be batched. The inverted index is the seam between them — queries read it, indexing writes it — so indexing a new SKU or a price change never blocks or slows a live query. Almost every design choice (eventual-consistency freshness, separate scaling tiers, graceful ranking fallback) flows from keeping those two pipelines independent.
Scale anchors
100M+ searchable SKUs; 1B+ queries/day; 10–20% autocomplete; 5–10× spikes during sales. These drive shard count and replication.
Key Highlights
- •A product search engine powers discovery + conversion: turns messy intent ('red running shoes size 9') into relevant products in milliseconds — great search drives revenue, slow/inaccurate search causes drop-offs
- •Must handle massive catalogs (100M+ SKUs), high query concurrency (campaign spikes), relevance + personalization, filters/facets, near-real-time indexing (new products, price changes)
- •The load-bearing idea: search is TWO systems decoupled by the inverted index — an ultra-low-latency read-heavy QUERY pipeline + an async batchable INDEXING pipeline; the index is the seam so indexing never blocks a live query
- •Almost every choice (eventual-consistency freshness, separate scaling tiers, graceful ranking fallback) flows from keeping the two pipelines independent; anchors 100M+ SKUs, 1B+ queries/day, 10-20% autocomplete, 5-10× spikes
Section Rescue Kit
Buzzwords to use:
Safe statements:
- "I will start with a basic inverted index and add relevance signals later."
- "Search quality and latency are both first-class requirements."
- "Facet performance must be sub-second for UX."