Design product catalogue search (Myntra / Flipkart)

Ecommerce queries are short and full of structure: brand, category, colour, size, price, gender. 'puma shoes for men size 9' is really brand=Puma, category=Shoes, gender=Men, size=9. If you send it as plain text to BM25, products whose description says 'not for men' or a Puma t-shirt might rank high. The query understanding service runs a pipeline: spelling correction (trained on query logs, careful with brand names like 'Mamaearth'), tokenisation, a dictionary and NER model that tags spans with attributes, a category classifier that predicts the top 1-3 categories with probabilities, and price/size parsers. Output is a structured query: filters for high-confidence tags, boosts for medium ones, and leftover free text for BM25. Show the interpretation to the user with an easy undo. Measure the classifier on precision, because a wrong hard filter causes zero results. For Hinglish and regional variations ('chappal', 'jutti'), mine synonyms from logs where different queries end in the same purchases.

Lexical BM25 is precise for brand names, model numbers ('iphone 15 128gb') and exact attributes, but fails on vocabulary mismatch ('sofa for small room' vs 'compact 2 seater'). Dense retrieval with embeddings handles meaning but can miss exact model numbers. Use both: run BM25 and an ANN query (HNSW, in OpenSearch/Elasticsearch k-NN or a vector DB) with the same filters, then fuse with reciprocal rank fusion. The re-ranker is a learning-to-rank model (LambdaMART or a small neural model) over ~400 candidates. Features: text match scores per field, category match probability, product CTR and conversion over 7/30 days (smoothed for new items), rating and count, return rate, price vs category median, discount, delivery days to the user's pincode, seller quality and personal affinity (brand, size, price band). Labels: graded from logs (order > add-to-cart > click > skip), with position-bias correction. Offline metric: NDCG@10 on held-out logs; online: A/B on search conversion and revenue per search. Add a rule layer for sponsored products in fixed, labelled slots.

The catalogue has three update speeds. Product content (title, attributes, images) changes rarely. Price changes often, especially in sales. Stock changes with every order. All flow from the source databases via CDC into Kafka, partitioned by style_id so updates for one product stay in order. Indexers batch partial updates into bulk requests every second; Elasticsearch makes them searchable after the refresh interval. During peak, raise refresh_interval to 5-10 s and coalesce repeated updates for the same style in the indexer, because 100 stock decrements in a minute only need one write. For stock, search only needs 'in stock or not' per size, not the exact count, so the indexer writes only when a size flips between in-stock and out-of-stock. Schema changes or new analysers require a full rebuild: build a new index from a snapshot of the catalogue while replaying Kafka from the snapshot offset, validate it, then atomically switch an alias. Never reindex in place.

A kurta style comes in 5 sizes and 3 colours, each a SKU with its own stock and sometimes its own price. If you index one document per SKU, results show the same kurta 15 times and facet counts are inflated. If you index one per style, filtering 'size M in stock' needs the per-size stock inside the style document. Common approach: one document per style (or per style-colour, since colour changes the image) with arrays like sizes_in_stock: [S, M, L] and min_price. Facet counts come from terms aggregations on keyword fields; they count styles, matching what the user sees. Nested documents are exact but slower; flattened arrays are fast and good enough when you design the fields carefully. Facet aggregations on high-cardinality fields like brand (100k brands) are expensive, so limit to top N buckets and cache facet results for popular category pages.

Elasticsearch/OpenSearch give text search, aggregations, kNN and operational tooling; most Indian e-commerce players started there. A custom engine (like Amazon's) makes sense only at very large scale with a dedicated team. Pick Elasticsearch and explain how you would shard it.

Hard filters give clean results but a wrong classification gives zero results. Boosts are safe but noisy. Use confidence thresholds, and if a filtered query returns too few results, retry with the filter turned into a boost.

Writing every stock change into the index is expensive. Index only in-stock flags per size and verify exact availability on the product page and at checkout.

Light personalisation (size, price band, gender, preferred brands) as re-ranking features helps conversion. Heavy personalisation makes results hard to debug and can feel creepy; keep the query intent primary.

10x traffic in the first hour. Pre-scale data nodes and replicas days before (Elasticsearch does not scale in minutes), cache results for the top 10k queries and category pages for 30-60 s, and switch the re-ranker to a cheaper model if latency rises.

Millions of price/stock updates compete with search for CPU. Coalesce updates, increase refresh interval, use dedicated ingest/coordinating nodes and throttle bulk indexing when search p99 crosses a threshold.

from/size beyond a few thousand results is costly. Cap pages (users rarely go past page 10) and use search_after for infinite scroll.

Fall back to the first-stage Elasticsearch order (BM25 + popularity function score). Results are slightly worse but returned on time.

A wrong rule like 'apple' -> fruit can tank a category. Version query understanding dictionaries, roll out behind a flag, monitor zero-result rate and conversion per query segment, and roll back in minutes.

Replicas take over; the cluster rebalances shards. Keep shard sizes small (10-20 GB) so recovery is quick, and run at most ~60-70% CPU at peak to absorb a node loss.