Catalogue Search Service

The client's search ran as SQL LIKE queries against the product table, which meant a misspelling or a plural returned nothing and merchandisers had no way to influence results. Their analytics showed a large share of sessions ending on an empty search page, and the category browse path carried nearly all the revenue as a result. They wanted search that tolerated real typing, and they wanted the merchandising team to be able to promote products for particular queries without an engineer.

I was the backend engineer on a three-person team with a frontend engineer and their in-house merchandising lead. My scope was the search service and the indexing pipeline. I was not involved in the search UI beyond agreeing the API contract, and I stayed out of the ranking-quality arguments, which the merchandising lead was far better placed to settle.

I built the indexing pipeline that keeps the search index in step with the catalogue — an outbox off the product database, a normalisation step, and a full rebuild path for when the incremental one drifts. I owned the query layer including analyzers, synonyms and the boosting configuration, plus the merchandising rules interface that lets the team pin or bury products per query. I set up the caching in front of it and the metrics that made relevance changes measurable. I didn't own the recommendation widgets, which came later and went to someone else.

I insisted on a full-rebuild path from day one even though incremental indexing was expected to be enough, because I've watched incremental indexes drift silently on every project where there wasn't one. It cost about a week and we've used it four times. I kept synonyms as a curated list the merchandising team edits rather than a learned model — the catalogue is small enough that curation is tractable, and a hand-edited list is something they can reason about when a result looks wrong. I also chose to store the search index as a derived artifact that can be thrown away entirely, which meant refusing several requests to keep merchandising state only in the index.

The catalogue has around sixty thousand products with descriptions from a dozen suppliers in wildly inconsistent formats, which made analyzers more work than the search itself. Reindexing had to happen without an availability gap because the storefront is always live. The client also had no appetite for a managed search service on cost grounds, so we ran it ourselves on their existing cluster with fairly tight resources.

Zero-result searches fell from a bit over a fifth of queries to around four percent, most of the remainder being genuine catalogue gaps the merchandising team now gets a weekly report of. Search-originated revenue roughly doubled as a share of the total over the first quarter, though a site redesign landed in the same window so I wouldn't claim all of it. The merchandising team has made several hundred pinning changes since launch, which tells me the tool fits how they work.

The merchandising lead defined what a good result was and reviewed every relevance change; my role was mostly to give her levers and get out of the way. The frontend engineer caught a set of API design mistakes early, particularly around how I was returning facets. The client's data team supplied the supplier feed mappings that made normalisation possible.