Search over content

The single biggest lever on perceived relevance is per-field analysis, and it's where weak answers stop at "put it in Elasticsearch."

The same source field is often indexed several ways for different jobs:

• Free text (name, description): tokenise, lowercase, stem ("running" → "run"), drop stop words. This is what BM25 scores against.
• Keyword (category, sku, brand): stored un-analysed for exact-match filtering and aggregations. If you tokenise a SKU, exact lookups break.
• Numeric (price, rating): numeric fields for range filters and sorting.
• Edge-ngram (autocomplete): index prefixes for type-ahead.

The most important distinction in the query is filter vs score. A category filter or price range is a must clause that narrows the candidate set but does not affect the relevance score — wrapping it in the scoring query both slows things down and pollutes ranking. Filters are also cacheable; scoring clauses are not. Getting this split right is the difference between "search feels precise" and "search returns garbage."

A field with the wrong analyzer fails silently: a search for "T-Shirt" returns nothing because the field was tokenised as "t" and "shirt" but queried as a keyword, or a stemmer collapses "apple" and "apples" when you needed them distinct. Always state which fields are text, which are keyword, and which are numeric.

The most common production failure in search is a dual write — the application writes the DB and the search engine in the same request handler. It works in the demo and breaks the first time the second write fails: now the DB says one thing and the index says another, permanently, because there's no mechanism to reconcile them.

The fix is to make the DB write the only synchronous write and derive the index from it:

• Transactional outbox: the app writes the business row and an outbox row in one transaction; a relay reads the outbox and publishes to Kafka. Atomic with the business write, no extra infrastructure on the write path.
• CDC (Debezium): tail the database's replication log and publish row changes directly. No app changes at all, but you couple to the DB's log format.

Either way, the indexer is an idempotent consumer: it upserts by doc_id, so replaying the same event twice (which will happen — Kafka is at-least-once) produces the same index state. The price is search lag: the index trails the DB by the pipeline latency, usually seconds. You accept that, monitor it as a first-class metric, and for the rare read-your-write case (a user searching for the thing they just created) you fall back to the DB for that specific item.

Relevance is where search stops being a database problem and becomes a product problem.

BM25 is the base. It scores a document by how often the query terms appear in it (term frequency), damped so the tenth occurrence matters less than the first, and weighted by how rare each term is across the corpus (inverse document frequency), with a normalisation for document length so long documents don't win by sheer size. It's a strong, parameter-light default — do not throw it away.

Layer business signals on top, never instead. function_score multiplies the BM25 score by boosts: log1p(sales) for popularity, an exponential decay on age for recency, a category boost for merchandising. The mental model is "BM25 ranks by textual relevance; boosts nudge toward business relevance." When the two fight — a textually perfect match for a discontinued product — you tune the weights, you don't discard BM25.

Two-phase retrieval keeps it fast. Expensive ranking (ML models, personalisation) can't run over the whole corpus. So phase one uses cheap BM25 to retrieve a candidate set (top ~1000), and phase two re-ranks only those candidates with the heavy signals. This bounds the expensive work to a fixed K regardless of corpus size.

Change relevance like you change production code. Every ranking change goes through offline evaluation (NDCG/MRR against a judged query set), then shadow traffic, then an A/B test measured on click-through and conversion — never "it looked better on my three test queries." Keep the old index and old model for instant rollback.

Analyzer changes, mapping changes, and new fields frequently require a full reindex — you can't retroactively re-analyse documents already in the index. If the search engine is the only copy of your data, you're stuck. Because the DB is truth, rebuild is routine.

The mechanism is versioned indexes behind an alias:

1. 1The application only ever queries the alias products, which currently points at products-v4.
2. 2Create products-v5 with the new mapping/analyzer.
3. 3Bulk reindex from the source DB (or the engine's reindex API) into v5.
4. 4Validate — run your judged query set against v5, compare relevance metrics to v4.
5. 5Atomically flip the alias from v4 to v5 (a single metadata operation — no downtime, no half-state).
6. 6Keep v4 around for a day for instant rollback; delete it once confident.

This is blue/green for search. The discipline it enforces — that the index can always be rebuilt from truth — is also your disaster-recovery story: if the cluster is lost or corrupted, you rebuild from the DB rather than restoring a possibly-stale snapshot.

At scale the index is sharded, and a query becomes a scatter-gather: the coordinator sends the query to every shard, each computes its local top-K, and the coordinator merges them into the global top-K.

Two subtleties matter in interviews:

Local-to-global correctness for ranking. Each shard must return enough candidates (and their scores) for the merge to be correct. Because IDF — the "how rare is this term" component of BM25 — is computed per shard by default, scores can differ slightly across shards for the same document; engines offer a global-IDF mode when consistent scoring matters, at the cost of an extra round trip.

Deep pagination is a tarpit. To return results 10,000–10,010, a naive fan-out makes every shard return its top 10,010 and the coordinator sorts 10,010 × shard_count documents to discard all but ten. Cost grows with the page offset. The fix is cursor / search-after pagination: pass the sort values of the last result as the starting point for the next page, so each page costs the same regardless of depth. Offer "next page" cursors, not arbitrary "jump to page 1000" offsets.

Shard sizing is the other operational lever: too many small shards waste coordination overhead, too few large shards limit parallelism and make rebuilds slow. Size shards to a few tens of GB and scale by adding shards (and replicas for read throughput) as the corpus grows.

BM25 matches terms. It cannot know that "laptop bag" and "notebook sleeve" mean the same thing, or that a query for "comfortable running shoes" should surface a product described as "cushioned trainers." That's the vocabulary mismatch problem, and it's where dense-vector (semantic) retrieval earns its place.

The hybrid recipe:

1. 1Embed documents (the same CDC stream feeds an embedding model) into dense vectors stored in an ANN index (HNSW).
2. 2At query time, run both retrievers — BM25 over the inverted index and k-NN over the vector index.
3. 3Fuse the two candidate lists. Reciprocal Rank Fusion (RRF) is the robust default: a document's fused score sums 1 / (k + rank) from each list, so it rewards documents that rank well in either retriever without needing the two score scales to be comparable.
4. 4Re-rank the fused candidates as usual.

The lexical half keeps exact-term precision (a search for a specific SKU or model number still works); the vector half adds semantic recall (synonyms, intent, paraphrase). The costs are an embedding pipeline to build and keep fresh, a vector index alongside the inverted index, and reduced explainability — it's harder to say why a semantically-retrieved result ranked where it did. Reach for hybrid when you can see BM25 leaving obviously-good results unmatched; don't add it speculatively.

Algolia built a business on the premise that relevance and speed are the product, and their public engineering writing is a masterclass in the ranking layer most candidates hand-wave.

Rather than a single opaque score, Algolia uses a tie-breaking ranking formula: a configurable, ordered list of criteria (number of matched words, proximity of the matched words, attribute importance, exactness, then custom business ranking like popularity) applied in sequence. Two results that tie on the first criterion are decided by the next, and so on. This is deliberately explainable — you can point at exactly which criterion ranked one product above another, which makes relevance tuning a conversation with product managers rather than a black box.

They also push hard on the type-as-you-search experience, treating sub-50 ms response as a hard requirement because every keystroke is a query. That forces the separation of concerns this pattern describes: a prefix-optimised index for instant suggestions, distinct from the main searchable attributes, with results ranked by popularity for the common-completion intent.

The takeaway for an interview: don't describe relevance as "BM25 and done." Describe an ordered, tunable, explainable ranking pipeline, and treat latency as a first-class constraint that shapes the index design.

Elasticsearch (and its OpenSearch fork) is the de-facto reference implementation of this pattern, and its design choices are worth citing directly.

It switched its default similarity from the classic TF-IDF to BM25 because BM25's term-frequency saturation and length normalisation produce better relevance out of the box — a concrete reminder that "use BM25" is the modern default, not TF-IDF. Relevance is then layered with function_score for popularity and recency boosts and bool queries that cleanly separate filter context (cacheable, non-scoring) from must context (scoring).

Its query execution is the canonical scatter-gather: the coordinating node fans the query to a copy of each shard, each shard returns its local top-K with document IDs and scores, and the coordinator merges them. Crucially, Elastic documents the deep-pagination problem explicitly and steers users away from large from/size offsets toward search_after (cursor) pagination and the scroll/PIT APIs for deep traversal — exactly because the naive approach forces every shard to over-return and the coordinator to sort an offset-proportional pile of documents.

And the alias-based reindex is first-class: the reindex API plus index aliases give you the zero-downtime, rollback-able rebuild that the pattern insists on.

Etsy's search serves a huge, long-tail marketplace where pure text relevance is far from enough — buyers care about quality, shipping, price, and recency, not just keyword overlap. Etsy's engineering team has written extensively about moving from hand-tuned scoring to machine-learned ranking (learning-to-rank), and the architecture is the textbook two-phase shape.

Phase one is candidate retrieval: a cheap lexical query (inverted index, BM25-style) pulls a few hundred to a few thousand plausible listings for the query. Running an expensive model over the entire corpus would be impossibly slow, so retrieval's only job is high recall at low cost.

Phase two is re-ranking: a learned model scores just those candidates using rich features — historical click-through and purchase rates, listing quality signals, price competitiveness, recency, and personalisation. Because it runs over a bounded candidate set, the expensive model's cost is independent of corpus size.

Etsy gates ranking changes behind offline evaluation and online A/B tests measured on engagement and conversion, not eyeballing — the discipline this pattern prescribes. The result is the standard production blueprint: cheap recall-oriented retrieval feeding an expensive precision-oriented re-ranker, with every change measured.