Understanding Elasticsearch Cluster Architecture: Nodes, Shards, and Deployment Strategies

Elasticsearch Cluster Architecture

Elasticsearch is an open‑source search and analytics engine that runs as a cluster of nodes. Each node hosts an Elasticsearch process and together they store and process data distributed across indices.

Key Concepts

Node : a physical or virtual machine running an Elasticsearch instance.

Index : a logical namespace that contains mappings and the inverted/forward index files; an index can span many nodes.

Shard : an index is split into primary shards for scalability; each shard is assigned to a node. Shards can be primary or replica .

Replica : a copy of a primary shard that provides redundancy and additional read capacity.

Indexing Process

When a document is indexed, a routing rule selects the target primary shard. The document is first written to the primary shard; only after the primary acknowledges success is the same document sent to all replica shards. The write is considered successful when every replica has acknowledged.

Role Deployment Models

Mixed (default) deployment : data, transport and master duties coexist on the same node. Requests may be sent to any node, which forwards them to the appropriate data nodes. This model is simple to start but can cause resource contention and limits the number of node‑to‑node connections.

Tiered deployment : node roles are separated. Transport nodes handle request routing and result merging, while data nodes store and process data. Isolation reduces interference, enables larger clusters and allows hot‑updates by upgrading data nodes independently of transport nodes.

Data Layer Architecture

Indices and metadata are stored on the local file system. Elasticsearch supports several storage back‑ends (niofs, mmap, simplefs, smb) and selects the optimal method automatically; mmap typically offers the best performance.

Replica count is configured per index. For example, a replica count of 2 creates three copies of each shard (one primary, two replicas) that are distributed across different machines or racks.

Service availability: if a replica fails, remaining replicas continue serving requests.

Data reliability: loss of a primary node does not cause data loss when replicas exist.

Read scalability: adding replicas increases query throughput proportionally.

Limitations of the Replica‑Based Architecture

Additional CPU, memory and storage consumption.

Write latency: each write must be propagated to the primary and all replicas.

Scaling delay: adding replicas requires a full copy of the shard data, which can be time‑consuming.

Distributed System Design Patterns

1. Local File‑System Based Distributed System

Each shard stores its data locally on the node that owns it. If a node fails, a replica is elected as the new primary and a new replica is created on another node, requiring a full data copy.

2. Distributed File‑System (Shared Storage) Based System

Storage and compute are separated. Shards contain only compute logic and reference data stored in a shared distributed file system (e.g., HDFS). When a compute node fails, a new node can attach to the same data without copying large volumes.

This architecture enables independent scaling of storage and compute, reduces waste, and improves hotspot handling, though shared‑storage access may incur higher latency than local disks.

Conclusion

The mixed and tiered deployment models present different trade‑offs. Choosing a model depends on workload characteristics, cluster size and operational requirements. Understanding node roles, shard distribution and replica strategies is essential for designing reliable, scalable distributed data systems such as Elasticsearch.