Lookup, filter or search? Watch the answer change shape.
If a unit test can check the answer, it’s a lookup or a filter. If engineers can argue about the order, it’s search.
LIKE '%kurta%' on 50M products?
Bad: Scan for it
Reads every row, ranks nothing, misses “kurtha”, finds “red” in “embroidered”.
Good: Look the word up
An inverted index: each term → the sorted IDs of products containing it.
125k×
less data than scanning for “kurta”
Assume 1 KB a row: the scan reads 50 GB, ≈ 50 s at 1 GB/s. Kurta’s 200,000 postings take ≈ 400 KB.
One Bazaar search box. Five kinds of search behind it.
Each part of the query goes to the machinery that suits it, then results are combined. Typeahead runs on its own fast path.
Vector search finds linen kurtas for “light office wear for May”. So drop keyword search?
Run both
Vectors blur model numbers and sizes. Run both retrievers and fuse ranks, not scores: 1 / (60 + rank).
Loosen the query: recall rises, precision falls.
Shoppers see 20 results, so top-20 precision is what they feel. A zero-result page is a recall failure that costs a sale.
Traps that bite in production
- Zero results: relax step by step, and say so
- Keep model numbers, sizes and SKUs exact
- The index is a copy: re-check price at checkout
Remember
Split first. Lookups and filters stay on database indexes; search needs an inverted index and ranking. Then name the kinds you blend, and whether precision or recall matters more.