The 30 second answer
First I clean and understand the query: tokenize, spell-correct, detect entities like brand or category, and decide redirects. Then base search retrieves a candidate set with lexical matching, filters, and optionally vectors. A later stage re-ranks with business rules and models, and may blend promotions. Facets are a separate aggregation-shaped call. Every optional enrichment sits behind a latency budget with a simpler fallback.
A strong interview answer draws a pipeline, not a single Elasticsearch query.
1. Query understanding. Normalize text (tokenize, casing, banned terms, spell correction). Run named-entity recognition so "Nike red trainers" becomes structured filters / boosted fields (brand=Nike, color=red, category≈shoes). Classify intents and redirects (bare brand → brand landing page). If nothing maps, mark the query as unconstrained and lean on semantic / embedding retrieval.
Public MICES 2026 talk notes (Zalando Search: Architecture Behind Product Discovery) describe standardization → dictionary NER + LLM NER → classification/redirects → enrichment → unmapped fallbacks, and a goal of avoiding empty result pages for real words.
2. Base retrieval (candidate generation). Elasticsearch (or similar) returns an initial set using lexical queries (BM25-style scoring over analyzed fields), structured filters, and optionally approximate kNN over product embeddings. Filters should be true filters (no scoring) for cacheability. Hybrid retrieval combines lexical and vector legs; fusion can be score-based or set-based (Opinion: start with a clear lexical baseline before adding ANN).
3. Presentation / fan-out. A catalog API may turn one user search into several backend queries (different cohorts, facet requests, A/B variants) and choose result page vs landing page. This layer is also a natural control plane for load shedding.
4. Re-ranking and policy. A separate service enriches candidates with user features and applies ML models plus rules (diversity, recently purchased down-rank, sponsored blend). Zalando's arXiv platform paper describes candidate generation (two-tower → top-500), a multi-task ranking transformer, and a policy layer for page composition. Their DoS post names an Algorithm Gateway for re-ranking / personalization / promotions.
5. Hydration. Return product ids (and scores) from search; fetch card fields from a product read API so the index stays lean.
Latency discipline. Put a hard p99 budget on the whole graph. Skip non-critical enrichments when time runs out. The MICES talk describes roughly splitting network vs processing and falling back when a step no longer fits — phrase as an engineering lesson, not a universal formula.
Sources:
- Elasticsearch — Boolean query
- Elasticsearch — kNN search
- Zalando Engineering — The Day Our Own Queries DoS'ed Us
- arXiv 2409.02856
- MICES / Mix-Camp talk listing — Zalando Search architecture (public talk; use as architecture narrative, not private spec)