A search product must choose between indexing throughput and query latency on the same hardware. How should the trade be made explicit and managed?

The trade

Indexing and querying compete for CPU, memory and I/O on the same data structures. Aggressive indexing degrades query latency; prioritising queries increases indexing lag. No configuration removes the conflict, and the only question is which one absorbs the pressure.

Making it explicit

• Declare which one degrades under contention, and implement it deliberately rather than letting the scheduler decide. A search product's users notice query latency immediately and indexing lag only sometimes, which usually argues for prioritising queries — but a product where freshness is the value proposition reverses that.
• Give indexing a rate limit rather than letting it consume whatever is available. A steady moderate rate is far better for query latency than bursts at full speed, even if total indexing throughput is lower.
• Batch index operations, since per-document indexing is dramatically more expensive than batched indexing, and the batch window is the explicit freshness-versus-throughput dial.
• Separate nodes for indexing and querying where the architecture permits, which converts a contention problem into a replication problem — usually a better trade because replication lag is bounded and measurable while contention is neither.

The failure mode to prevent

A bulk reindex during peak query load. It is the single most common way a search cluster becomes unusable, and it is usually triggered by something routine: a mapping change, a schema migration, a data backfill.

The controls: treat full reindex as a scheduled, rate-limited, rehearsed operation, run it against a separate index and swap on completion rather than rebuilding in place, and make the swap atomic so there is no window with a partial index serving traffic.

The property that makes a simpler engine attractive

An engine that makes this trade for you — predictable near-real-time behaviour, a small operational surface, a lower ceiling — frequently produces better outcomes than a powerful one tuned badly. The ceiling is only a problem if you reach it; the tuning burden is paid every day.

That is a genuine architectural choice rather than a maturity difference, and the deciding inputs are the corpus size in two years and whether the team has search expertise to spend.