A search platform receives continuous document updates while users expect newly published content to appear quickly. How should indexing pipelines, replicas, refresh intervals, cache invalidation and query serving be separated?

The central tension

Indexing and querying compete for the same resources, and freshness is bought directly with query performance. A short refresh interval creates many small segments, which every query must then examine; merging them costs I/O that competes with search. There is no configuration that gives both.

So the design must decide which content needs to be fresh, rather than making everything fresh.

The separation that works

• Tier by freshness requirement, not by content type. A small, hot index holding recent documents with an aggressive refresh, and a large main index refreshed lazily. Queries hit both and merge results. This is more machinery and it is the only approach that gives sub-second freshness without paying for it across the whole corpus.
• Separate indexing nodes from query nodes where the platform permits, so a bulk reindex cannot degrade search latency.
• Bulk and batch writes. Per-document indexing is dramatically more expensive than batched indexing, and the batch window is a direct freshness-versus-throughput dial.
• Treat a full reindex as a routine operation, built and rehearsed, because mapping changes require one and a team that has never done it will do it badly under pressure.

The read path

• Cache query results with a short TTL, keyed on the query and filters. Search traffic is extremely skewed — a small number of queries dominate — so a small cache gives a large hit rate.
• Do not attempt precise invalidation of search result caches. The relationship between a document change and the queries it affects is intractable; a short TTL is the pragmatic answer.
• Serve stale results while revalidating during an indexing backlog, rather than failing.

The requirement to challenge

"Users expect newly published content to appear quickly" is rarely uniformly true. The author must see their own document immediately — which is a read-your-own-writes problem solvable by reading from the primary or from a local cache, not by making the whole index fresh. Everyone else can usually tolerate seconds or minutes.

Separating those two cases removes most of the cost, and it is the design conversation that should happen before any refresh interval is tuned.