Spring Data Elasticsearch write versus search: refresh is the visibility boundary

Distinguish write acknowledgement from search visibility

An order-search document is indexed and the HTTP write returns success. A search request made immediately afterward can still miss it until Elasticsearch refreshes the relevant shard. A direct get by ID and a search have different visibility paths. Do not write a test that asserts immediate search visibility without choosing a refresh policy. An asynchronous projector adds another delay before the write even reaches Elasticsearch.

Choose where to pay

For an admin workflow that must search a newly written document, request a refresh behavior or refresh the index in a narrow test. Refreshing after every write lowers indexing throughput and can increase segment work. For a public feed, show the accepted write from the primary database while search catches up, or return a versioned pending state. The source database remains the system of record.

Test the two paths

Index a document, immediately read it by ID, and search for it before and after an explicit index refresh. Assert the UI's promised behavior, not a timing accident on a fast local node. The snippet forces visibility only for a controlled test or narrow operation; it is not a blanket production setting.

Implementation sketch

IndexOperations index = elasticsearchOperations.indexOps(
    IndexCoordinates.of("orders-read-v4"));
index.refresh();
SearchHits<OrderSearchDocument> hits = elasticsearchOperations.search(
    searchQuery, OrderSearchDocument.class);

Cost and verification

Refresh work increases as write rate rises. A delayed-search contract can preserve indexing throughput, but the UI must not claim the result is complete before the projection catches up.

Common Mistakes

• Do not equate write acknowledgement with immediate search visibility.
• Do not refresh the index after every write without measuring the indexing cost.
• Do not use a search index as the only durable record of an order.

Read next

Spring Data MongoDB change stream: resume token and idempotent projection, Spring Data Elasticsearch sequence conflict: do not overwrite a newer projection, Spring Data Elasticsearch mapping rollout: build a new index, then move the read alias, Spring outbox transaction boundaries: where atomicity ends.