Freshness Tiering

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

Freshness tiering resolves it by scope rather than by tuning: a small hot index holding recent documents, refreshed aggressively, plus a large main index refreshed lazily, with queries hitting both and merging results.

Why it matters

It converts a global cost into a local one. The expensive property is applied to a tiny fraction of the corpus, so the aggregate cost is small — which is the same structural move as strong consistency at the point of commitment and eventual consistency everywhere else.

Implementation patterns

• Tier by freshness requirement, not by content type. The dimension that matters is how soon it must be visible, and that is usually recency rather than category.
• Age documents out of the hot tier into the main index on a schedule, and make that transition idempotent so a document is never briefly absent from both.
• Merge results at query time, with deduplication by document ID so an in-transit document is not returned twice.
• Separate indexing nodes from query nodes where the platform allows, so a bulk reindex cannot degrade search latency.
• Batch writes, and treat the batch window as the explicit freshness-versus-throughput dial — per-document indexing is dramatically more expensive than batched indexing.
• Treat full reindex as a rehearsed routine operation. Mapping changes require it, and a team that has never done one will do it badly under pressure.

Industry example

Search platforms such as Elastic and lighter-weight engines such as Meilisearch and Typesense make different choices here, and the difference is instructive. The large distributed engines expose refresh intervals, segment merging and replica behaviour as tunable, which is powerful and demands expertise. The simpler engines choose predictable near-real-time behaviour with a smaller operational surface and a lower ceiling.

That is a genuine architectural trade rather than a maturity difference: a team without search expertise often gets better outcomes from a simpler engine's opinionated defaults than from a powerful one they tune badly.

Failure scenarios

• Refresh interval lowered globally to satisfy one requirement, degrading query latency for the whole corpus.
• A document missing from both tiers during transition, because the hand-off was not idempotent.
• Duplicates returned because the merge did not deduplicate.
• The freshness requirement never challenged — the author needs to see their own document immediately, which is a read-your-own-writes problem solved by reading the primary, not by making the whole index fresh. Everyone else usually tolerates seconds.
• No rehearsed reindex, so a mapping change becomes an incident.

Trade-offs

Two tiers is more machinery: two indices to operate, a transition process, a merge at query time, and deduplication. For many products the simpler answer — accept a few seconds of latency across one index, and solve read-your-own-writes separately — is better.

Tiering earns its cost when the corpus is large and the freshness requirement applies to a small recent slice, which is the common shape in marketplaces, news and social products. It does not earn its cost when the corpus is small enough to refresh cheaply.

Interview question

"Product says new listings must be searchable within one second. Your index has two hundred million documents. What do you ask them before you build anything, and what do you build if the answer is that they mean it?"