Billions of Logs in Seconds: How Elasticsearch Makes It Possible

Elasticsearch can return results for a keyword within a few hundred milliseconds even when tens of thousands of logs arrive each second. This speed is not magic; it relies on sharding, an inverted index, and a two‑phase query architecture that turn "searching a needle in a haystack" into "guided retrieval".

Write Path: Data Does Not Go Directly to Disk

New documents are first placed into an index buffer in JVM memory while a translog entry is appended for durability. Every second a refresh creates an immutable segment file; only after this segment exists can the data be searched. Segments are immutable—once written they cannot be modified. Deletions are marked with a .del flag, and updates are performed as delete‑then‑add. Real space reclamation occurs later when background merges combine small segments into larger ones. Because of this design Elasticsearch is I/O‑intensive, so hot data is kept on SSDs and cold data on spinning disks, and indices are often created per day to limit the time range scanned.

Two‑Phase Query: Query Then Fetch

When a query is issued, the coordinating node broadcasts it to all relevant shards (randomly picking one replica per shard for load balancing). Each shard uses its local inverted index to match terms, score documents, and return only DocID plus score. The coordinating node merges these results, performs a global sort, and selects the document IDs needed for the requested page. In the fetch phase, the coordinating node retrieves the full source of those IDs from the appropriate shards and assembles the final response. This design incurs a cost: deep pagination forces every shard to process all preceding results, so Elasticsearch caps the default maximum returned hits at 10,000 and advises against using it as a database‑style paginator.

Inverted Index: Three‑Layer Precise Positioning

The core of full‑text search is the inverted index, which differs fundamentally from MySQL’s B‑Tree. It consists of three layers:

Term Index – an FST (finite‑state transducer) kept in memory that maps term prefixes to dictionary blocks on disk, enabling millisecond‑level look‑ups.

Term Dictionary – a sorted, compressed store that holds pointers to the posting lists and also supports fuzzy matching.

Posting List – records for each term indicating which documents contain it, the positions, and term frequencies, which are later used for scoring.

During a query the flow is: tokenization → memory locate (Term Index) → disk read of Term Dictionary → fetch Posting List → compute scores → return top N documents. By turning a full scan of all documents into a dictionary lookup, Elasticsearch achieves the “second‑search” performance.

Putting It All Together

Elasticsearch’s search capability is the result of three stacked designs: the write path uses immutable segments and asynchronous merges for high‑throughput ingestion; the query path employs a two‑phase broadcast‑and‑gather mechanism for distributed full‑text search; and the index layer’s three‑layer inverted structure reduces an O(N) document scan to O(1) dictionary look‑up. The overall formula can be expressed as:

Big‑data retrieval = sharding parallelism + inverted‑index positioning + coordinated aggregation.

In interviews, mentioning this layered architecture is far more informative than simply stating that Elasticsearch is "fast".

#Elasticsearch #InvertedIndex #DistributedSearch #HighConcurrency #BackendInterview