How does Elasticsearch achieve near real-time search?
Learn how Elasticsearch delivers near real-time search via refresh, in-memory buffers, immutable Lucene segments, and the translog, with tuning examples.
Expected Interview Answer
Elasticsearch achieves near real-time (NRT) search through a periodic refresh operation that turns recently indexed documents held in an in-memory buffer into a new searchable Lucene segment, by default about once per second, making documents searchable shortly after they are indexed rather than instantly.
When a document is indexed it lands in an in-memory buffer and is appended to a translog for durability, but it is not yet searchable. A refresh moves the buffer's contents into a new, immutable Lucene segment in the filesystem cache and opens it for search; this is why there is a small delay (the refresh interval) rather than true real-time visibility. Separately, a periodic flush fsyncs segments to disk and clears the translog. Refresh is relatively cheap but not free, so under heavy indexing you can raise the refresh_interval to boost throughput at the cost of a longer visibility delay.
- New documents become searchable within about a second
- Buffering writes keeps indexing fast
- The translog guarantees durability before disk flush
- Immutable segments enable efficient caching and merging
- Tunable refresh_interval trades latency for throughput
AI Mentor Explanation
As runs are scored they are first jotted on a scorer's rough notepad, not yet on the public scoreboard. Roughly every over the scorer copies the notes onto the big board so the crowd can read them. That periodic copy is like the refresh: new runs are not visible the instant they happen but appear a short, predictable moment later once the board is updated.
Step-by-Step Explanation
Step 1
Buffer the write
An indexed document is placed in an in-memory indexing buffer on the target primary shard and is not yet searchable.
Step 2
Append to the translog
The operation is written to the transaction log so it can be recovered if the node crashes before segments reach disk.
Step 3
Refresh into a segment
Every refresh_interval (default 1s) the buffer is written to a new immutable Lucene segment in the filesystem cache and opened for search.
Step 4
Serve the new document
Once the new segment is opened by a refresh, its documents become visible to subsequent searches, hence near real-time.
Step 5
Flush and merge
Periodically a flush fsyncs segments to disk and truncates the translog, while background merges combine small segments into larger ones.
What Interviewer Expects
- Explanation of the refresh operation and refresh_interval
- Understanding of the in-memory buffer and immutable segments
- Role of the translog for durability
- Distinction between refresh (searchability) and flush (durability)
- Awareness of the throughput vs visibility-latency tradeoff
Common Mistakes
- Claiming documents are searchable the instant they are indexed
- Confusing refresh with flush
- Ignoring the translog's role in durability
- Thinking Lucene segments are mutable
- Not knowing refresh_interval can be tuned for bulk indexing
Best Answer (HR Friendly)
“When you add data to Elasticsearch it isn't searchable the very instant it's saved. About once a second Elasticsearch runs a quick refresh that makes newly added data available to search, so results appear almost immediately. This small, predictable delay is why it's called near real-time rather than truly instant.”
Code Example
POST /products/_refresh
PUT /products/_settings
{
"index": {
"refresh_interval": "30s"
}
}
PUT /products/_doc/2?refresh=wait_for
{
"name": "Mechanical Keyboard",
"price": 89.0
}Follow-up Questions
- What is the difference between a refresh and a flush?
- What role does the translog play in durability?
- How would you tune indexing for a large bulk load?
- Why are Lucene segments immutable, and how are deletes handled?
- What does the refresh=wait_for parameter do on a write?
MCQ Practice
1. What operation makes newly indexed documents searchable in Elasticsearch?
A refresh writes the in-memory buffer to a new Lucene segment and opens it for search, making recent documents visible.
2. What is the default refresh interval for an active index?
By default a shard refreshes about once per second, which is why search is near real-time rather than instant.
3. Which component ensures durability before segments are fsynced to disk?
The translog records each operation so it can be replayed and recovered if the node fails before a flush persists segments to disk.
Flash Cards
Why is Elasticsearch search 'near real-time'? — New documents become searchable only after a periodic refresh (default ~1s), not the instant they are indexed.
What does a refresh do? — It writes the in-memory buffer to a new immutable Lucene segment in the filesystem cache and opens it for search.
What is the translog for? — Durability, it records operations so they can be recovered if a node crashes before segments are flushed to disk.
Refresh vs flush? — Refresh makes documents searchable; flush fsyncs segments to disk and truncates the translog.