The write and the searcher follow different schedules
The primary shard handles the indexing request and coordinates replicas according to the engine's write protocol. Lucene builds the searchable representation, while the translog supports recovery from operations not yet included in a Lucene commit. Under Elasticsearch's default request-level translog durability, the system fsyncs the relevant translogs before acknowledging a successful request. Configuring asynchronous translog durability changes that guarantee and can expose acknowledged operations to loss after a failure.
A refresh is a different operation. It makes recently indexed documents visible to search without requiring a full Lucene commit. Background refresh timing depends on settings and whether shards are actively searched. Elastic's general documentation describes a one-second default in the Elastic Stack and different defaults for Serverless, with search-idle optimizations. Those are defaults, not a per-request deadline you should promise without measuring the entire pipeline.
A flush performs a Lucene commit and starts a new translog generation. Flush and refresh answer different questions. Forcing a flush to make one product searchable confuses recoverability with visibility. Flush is not the appropriate routine tool for low-latency search publication.
Segments are also not rewritten in place for every update. New segments and deletion markers accumulate. Background merges can combine smaller segments into larger ones, reclaiming some deleted data and simplifying future searches. Merging consumes disk IO, CPU and temporary space. It is not a prerequisite to making each new document searchable. If the team forces a refresh for every single write, it can create many tiny searchable segments and increase merge pressure later.
Walk the exact user-visible timeline
At 12:00:00.000, the product service receives an update for product P-482. It writes to the authoritative catalog and a separate indexing path sends version 18 to Elasticsearch. At 12:00:00.080, indexing receives an acknowledgment. A direct real-time GET may show version 18. At 12:00:00.250, a query runs against a searcher that still sees the previous refresh snapshot. It returns no hit. At 12:00:01.100, the affected shard refreshes and later searches can see version 18, assuming the query, analyzer, filters and routing also match.
Those times are illustrative, not an Elasticsearch service-level guarantee. In a real deployment the product update may also wait behind a queue, retry an indexer, or search a replica with a different current view. Measure each stage. If the application promises "searchable within five seconds," start the clock at the authoritative catalog commit, not at an internal indexing request that might have sat in a queue for four seconds already.
What would I do for a user who creates a listing and immediately opens its page? I may provide read-your-write behavior by serving the detail view from the catalog or a version-aware preview, not by forcing all search infrastructure to synchronously publish every document. If the workflow explicitly requires searching the new listing before responding, Elasticsearch supports refresh=wait_for on relevant write APIs. It waits for a refresh rather than forcing one immediately. It affects response latency and has operational caveats, so I'd reserve it for workflows with that contract.
Test the trade-off under actual update traffic
Forcing refresh=true after every request can make indexing appear correct in a trivial test while harming production throughput. I would track indexing latency, age of the oldest unapplied source change, refresh time, segment count, merge backlog, search p99, translog flush/replay behavior and version visibility from multiple search replicas. I'd inject sustained bulk indexing while search is live, then measure a percentile of end-to-end freshness and the worst-case tail.
Updates and deletions also deserve separate tests. A modified product might be visible with old fields for a short time. A deleted product might linger until refresh, which is a different issue from whether an operation is durable. Safety-sensitive removal or authorization revocation requires stronger protection, potentially at the query gateway or authoritative store. Do not claim that a one-second refresh interval provides an immediate access-revocation guarantee.
The interview question is really about naming the correct boundary. Acknowledged, searchable, durably committed to a Lucene point, and fully merged are not the same state. Once the team draws those as separate stages, the right fix becomes a measured freshness policy, not an expensive flush after every click.
