Elasticsearch Series Part 1: Introduction to System Concepts and Read/Write Flow

Elasticsearch, short for Elastic Search, is a distributed search middleware originally created by its founder while building a recipe‑search app for his wife; it has become a widely used, high‑performance, near‑real‑time search solution capable of handling many data types.

Cluster

A cluster consists of multiple Elasticsearch (ES) instances (nodes) managed by a master node elected to ensure high availability and avoid single‑point failures; not every node can be a master‑eligible candidate.

Any single ES instance can also form its own cluster.

Typical cluster architecture is shown below:

Node Roles

Each ES instance is a node and can assume one or more of the following roles:

Master‑eligible Node

Only master‑eligible nodes can participate in master election; the elected master creates and deletes indices, tracks node membership, decides shard allocation, and monitors cluster health. For stability, it is recommended to run at least three low‑spec dedicated master‑eligible nodes.

Data Node

Data nodes store the actual data and handle CRUD, aggregation, and search operations; they require high CPU, memory, and I/O resources. It is advisable to separate data nodes from master nodes to avoid split‑brain scenarios.

Use SSDs to improve disk I/O.

Reserve memory for file cache beyond the JVM heap.

Disable swap.

Coordinating Node

Any node that receives a client request acts as the coordinating node, routing the request to the appropriate shards, merging results, and returning the final response. Its load lies between master and data nodes, so isolating it can reduce pressure on data nodes.

Other optional node types include Ingest, Remote‑eligible, Machine Learning, and Transform nodes.

Shard and Replica

A data node can hold multiple shards; each shard is a Lucene instance. An index is composed of many primary shards, which are immutable after creation. Each primary shard can have zero or more replica shards (default one) that never reside on the same node as the primary, providing fault tolerance and read‑scale.

Lucene

Elasticsearch builds on Apache Lucene, a full‑text search library. A Lucene index consists of immutable segments, each containing a built‑in inverted index. Deletions are marked, and updates are performed as delete‑then‑add of a new segment.

Write Process

When a coordinating node receives a write request, it routes the request to the appropriate primary shard, which writes to the index buffer and the transaction log (translog). The data becomes searchable only after a refresh (default 1 s) creates a new immutable segment. Flushing writes the segment to disk and clears the translog.

Flush can be triggered manually:

curl -XPOST "http://127.0.0.1:9200/_flush/synced"

Or per index:

curl -XPOST "http://127.0.0.1:9200/demo/_flush/synced"

Segments are periodically merged to reduce file count and improve search speed; forced merge can be invoked when load is low:

curl -X POST "http://127.0.0.1:9200/demo/_forcemerge"

Search Process

The first node that receives a search request acts as the coordinating node, distributes the query to all relevant shards, merges the results, and returns them. For pagination, the coordinating node may request more documents from each shard than needed and then trim the final page.

Elasticsearch limits deep pagination to 10 000 results by default. Work‑arounds include:

Increase index.max_result_window :

curl -XPUT "http://127.0.0.1:9200/demo/_settings" -H 'Content-Type: application/json' -d'{"index.max_result_window": "1000000"}'

Use scroll API to keep a snapshot of the index and iterate through results:

curl -XGET "http://127.0.0.1:9200/demo/_search?scroll=10s" -H 'Content-Type: application/json' -d'{"size":20,"query":{"match_all":{}}}'

The response contains a _scroll_id which is used for subsequent calls:

{"_scroll_id":"i1BOVdVWjJyU...", ...}

curl -XGET "http://127.0.0.1:9200/_search/scroll" -H 'Content-Type: application/json' -d'{"scroll":"10s","scroll_id":"i1BOVdVWjJyU..."}'

When finished, delete the scroll context:

curl -XDELETE "http://127.0.0.1:9200/_search/scroll" -H 'Content-Type: application/json' -d'{"scroll_id":"i1BOVdVWjJyU..."}'

Use search_after for stateless deep pagination by sorting on a stable field (usually _id ) and providing the last sort values from the previous page:

curl -XGET "http://127.0.0.1:9200/demo/_search" -H 'Content-Type: application/json' -d'{"from":0,"size":10,"query":{"match_all":{}},"search_after":[674688494483205],"sort":[{"_id":{"order":"desc"}}]}'

Conclusion

This article provides a brief overview of Elasticsearch's core system concepts, write and search workflows, and shows how its architecture resembles that of many distributed databases; future articles will dive deeper into the underlying principles and performance tuning.

References

Elasticsearch official documentation: https://www.elastic.co/guide/en/elasticsearch/reference/current/index.html