The 30 second answer
Search is a derived view, so it lags the write side by design. I set an explicit lag SLO for price and stock, push those fields on a faster path than rare attribute edits, and always re-validate at checkout. Users may see a brief mismatch; the buy path must not. After a merchant edit I may read the primary service for that id. I never pretend the index is strongly consistent.
Why lag exists. Async replication into a search index means a successful product update can be invisible to shoppers for some window. DDIA's replication chapters cover replica lag and read-your-writes tactics (for example, reading from the leader for recently written data). Elasticsearch itself is near-real-time: documents become searchable after a refresh, not after the index API returns (Elasticsearch in Action Ch refresh discussion; Elastic docs: refresh interval).
Product consequences.
- Stale price → trust issues.
- Stale in-stock → failed checkout.
- Stale title → milder annoyance.
Design moves (Opinion, grounded in common patterns).
- Separate fast lanes for price/stock events from slow attribute reindexes.
- Publish versions / timestamps on documents; ignore older events in the join processor (Zalando Flink enrichment post drops older-timestamp events).
- Checkout and cart APIs re-fetch authoritative price/stock from the write model.
- Merchant "preview" UIs may call
_refreshor a primary read path — never make global refresh_interval tiny just for that. - Communicate soft availability ("few left") when exact counts are cached.
What to say in the interview. "We choose eventual consistency for discovery throughput; we bound it with lag SLOs and we never authorize purchase from the search replica."
Sources:
- Elasticsearch — Near real-time search / refresh
- DDIA — replication lag / read-your-writes (study map theme 7)
- Zalando Engineering — Flink offer enrichment
- Zalando Engineering — Product read API / event-driven serving