The 30 second answer
Product creates and updates stay in an operational store with clear ownership. Search gets its own denormalized documents built asynchronously from change events. That is CQRS in practice: the write side protects invariants, the read side optimizes for filters, facets, and ranking features. I accept eventual consistency and design explicit lag SLOs plus backfill. I would not let checkout read stock from Elasticsearch.
Problem. A normalized product database is good for writes and integrity (one product, many offers, many locales). It is a poor shape for "red Nike running shoes under €100 in NL, sorted by relevance then popularity." Search needs denormalized documents, inverted indexes, aggregations, and often vectors.
Pattern. Use CQRS-style separation:
- Write / command side: product master, offers (price/stock), enrichment metadata. Own teams can own ingestion vs serving (Zalando's public Product Data Serving write-up splits Partners & Supply from Product Data Serving).
- Read / query side: one or more search indexes and optionally a low-latency product read API for card hydration.
Change propagation is asynchronous: outbox or CDC → event bus → stream processors → bulk index API. DDIA frames CDC as streaming a logical log to build indexes and caches, and describes deriving read-optimized views from events (materialized views / CQRS themes).
What belongs in the search document (Opinion). Stable identity (SKU / product id), searchable text per language, filterable attributes as keyword/numeric fields, ranking features (popularity, margin band, newness), availability flags, and embedding fields if you do vector retrieval. Keep bulky media URLs out of scoring paths when possible; hydrate cards from a product read API after retrieval returns ids — a pattern Netflix has described for studio search (return keys, hydrate via graph).
Consistency contract. Tell the interviewer explicitly: catalog text may lag seconds to minutes; price/stock should be nearer real time; checkout always re-validates against the write side. Search is eventually consistent by design.
Sources:
- DDIA — CDC / logical logs and derived views (study map themes 9; early-release text on CDC and CQRS-style derived data)
- Zalando Engineering — From Event-Driven Chaos to a Blazingly Fast Serving API
- Netflix TechBlog — GraphQL search indexing (named Netflix analogy: thin events, re-fetch, return keys)
- microservices.io — CQRS