The 30 second answer
I separate discovery from commerce writes. Search must be fast, highly available, multilingual, and good enough that empty results are rare, while price and stock stay eventually consistent. Booking-style strong consistency belongs to checkout, not the search index. The hard trade-offs are freshness versus indexing cost, precision versus recall, and personalization versus a strict latency budget. I would state SLOs for p99 latency, index lag, and relevance quality up front.
Product search has two jobs that pull in opposite directions.
Functional. Users type free text, apply filters (brand, size, color, price), browse categories, and expect facets that update with the current result set. Merchants and partners change title, attributes, price, and stock continuously. Sponsored or promoted items may be blended with organic results. Some platforms also expose the same retrieval backend to assistants or conversational entry points.
Non-functional. Discovery traffic is read-heavy and latency-sensitive. Availability matters more than perfect freshness for most listing fields, but stale price or stock that looks "buyable" creates bad UX and support load. Multilingual catalogs need language-aware analysis. Peak events (sales weeks) amplify both query QPS and update rate.
Core trade-offs to name in the interview
- Freshness vs cost. Indexing every attribute change immediately is expensive; batching hurts price/stock truthfulness.
- Precision vs recall. Strict matching looks "right" but creates zero-result pages; loose matching fills the page with weak hits. Relevant Search treats matching and ranking as separate steps and argues you should never leave the user on an empty page — relax, spell-correct, or show possibly relevant results and tell the UI what you did (Ch8).
- Personalization vs latency. Extra model hops improve engagement but consume the p99 budget; production systems often skip enrichment steps when the budget is gone.
- Strong consistency vs search scale. Seat inventory or payment ledgers need strong writes; a search replica of the catalog should not be the source of truth for checkout.
Opinion: in an interview, put hard SLOs on the whiteboard early: end-to-end search p99, maximum acceptable index lag for price/stock, and how you will measure relevance (offline judgments + online A/B). Without those, every later choice is hand-waving.
Engineering lesson (public Zalando sources). Zalando's Search & Browse path uses Elasticsearch for base candidates (lexical and vector), a query-understanding / NER layer, a catalog/presentation layer that can fan out queries and own redirects/facets, and a later re-ranking / algorithm layer with personalization and promotions. Their Dec 2025 incident post describes that layered query path and per-layer caching; their arXiv ranking platform paper reports a 500 ms end-to-end SLO with roughly 200 ms observed for the personalized ranking path in that system. Treat those as published reference points for one large fashion marketplace, not universal constants.
Sources:
- Relevant Search — Ch8 relevance feedback / empty results (synthesis from Ch8; empty-result guidance around the book's "never show an empty page" discussion)
- Designing Data-Intensive Applications (early-release notes) — full-text search / inverted indexes (Ch3 discussion of inverted indexes; see also local study map theme 1)
- Zalando Engineering — The Day Our Own Queries DoS'ed Us
- arXiv 2409.02856 — Building a Scalable, Effective, and Steerable Search and Ranking Platform