Typesense Faceted Search & Typo Tolerance at Scale

Getting Typesense running takes an afternoon. Getting it to feel right is where the actual work is.

Typesense makes fast, typo-tolerant search approachable, and the starter setup works impressively well out of the box. The distance between that and search a customer trusts is a set of details — facets, synonyms, relevance and keeping the index honest — that a comparison article does not have room for. This is that layer.

Facets are filters and rankers at once

Faceted search — brand, size, price range, category — does two jobs: it narrows results and it shows the user what refinements exist and how many results each yields. Mark the right fields as facets at schema time, keep their cardinality sane, and apply facet filters before relevance ranking so the counts the user sees match what they get when they click.

  • Declare facet fields in the collection schema; you cannot facet on what you did not mark
  • Filter first, then rank — so facet counts and results agree
  • Watch high-cardinality facets; thousands of values make an unusable filter list

Typo tolerance needs a leash

Typo tolerance is why Typesense feels forgiving, but unbounded it starts matching things the user never meant — a two-character edit on a short word is a different word. Tune the number of allowed typos by token length, and require more of the query to match on longer inputs, so “iphone case” does not quietly return “iphone cable.”

Typo tolerance is a dial, not a switch. Too tight frustrates; too loose returns nonsense confidently.

Synonyms close the vocabulary gap

Customers do not use your catalogue’s words. They search “sneakers” when you wrote “trainers,” “sofa” when you wrote “couch,” a brand’s nickname instead of its full name. Synonyms map their language onto yours so a real query does not return nothing. Mine your zero-result searches for the pairs that matter — that log is a list of sales you are losing.

# a synonym set: any of these matches the others
{
  "synonyms": ["sneakers", "trainers", "running shoes"]
}
# source your sets from real zero-result queries, not guesses

Relevance is weighting, deliberately

Not every field deserves equal say. A match in the product title should outrank a match buried in a description, and you often want business signals — in stock, popularity, margin — to nudge ranking. Set field weights and sensible tie-breakers so the first result is the one the customer most likely wants, not merely a valid match.

  • Weight title and key attributes above long-form description text
  • Break ties with a business signal like popularity or availability
  • Test ranking against real queries, not a handful of favourites

The index has to stay in sync

The failure that erodes trust slowly is a stale index: a product goes out of stock or changes price, the index still shows the old state, and customers hit dead ends. Update the index on the same events that change the source data — ideally through a queue so a burst of changes does not overwhelm it — and reconcile periodically to catch anything the event stream missed.

Where the effort pays

Speed gets the credit in demos; facets, synonyms, tuned relevance and a fresh index are what make people actually find products and buy them. That is the half of search that never shows up in a feature comparison and makes all the difference in the conversion numbers.

From the same work

Search that never finds the product?