Elasticsearch Cluster Architecture: Nodes, Shards, and Replicas
Fast recall
Quick revision
Core answer
Whether you can explain the distribution model and understand the operational implications of shard count, replica count, and node roles.
Setting too many primary shards at index creation (shards are fixed and cannot be changed without reindexing). Elasticsearch recommends 10-50 GB per shard as a target.
Discuss the split-brain problem and how the master election quorum (minimum_master_nodes or cluster.initial_master_nodes in 7.x+) prevents it, and explain the write and read paths across primary and replica shards.
Interview-ready guide
Interview answer
An Elasticsearch cluster distributes data across nodes using shards. Every document lives in exactly one primary shard, and sharding is what allows Elasticsearch to scale search horizontally.
Shards — the unit of distribution
- An index is divided into N primary shards, each containing a portion of the documents;
number_of_shards: 3distributes the index across 3 physical Lucene segments across the cluster - The number of primary shards is fixed at index creation — it cannot be changed after indexing; choose based on expected dataset size, targeting 20-30GB per shard as a practical guideline
- Search queries fan out to all shards in parallel — each shard executes the query locally and returns its top results; the coordinating node merges and ranks the per-shard results into the final response
Replicas — for HA and read throughput
- Each primary shard has zero or more replica shards —
number_of_replicas: 1means every primary has one replica on a different node - Replica shards also serve search requests — which means adding replicas increases read throughput, not just durability; a cluster with 3 primaries and 1 replica per primary has 6 shards total serving search requests
- Replica count can be changed anytime — set to 0 during bulk indexing for speed (no replication overhead), then restore to 1 after
Node roles
- Master-eligible nodes coordinate cluster state changes — shard allocation, index creation, node joins; one is elected as the active master
- Data nodes store shards and execute queries and indexing — the compute-and-storage nodes; scale horizontally as data grows
- Coordinating-only nodes receive client requests, fan them out to data nodes, and merge results — useful to offload merge work from data nodes at high query volume
A minimum production cluster has 3 master-eligible nodes (to form a quorum and prevent split-brain) and separate data nodes scaled to the dataset size.
Elasticsearch Cluster Architecture: Nodes, Shards, and Replicas
Direct Answer
An Elasticsearch cluster is a group of nodes that collectively store and search data. Data is divided into shards (primary shards hold the actual data; replica shards are copies for fault tolerance and read throughput). Each shard is a self-contained Lucene index. Nodes take on roles -- master (cluster coordination), data (shard storage), coordinating (query routing) -- and can serve multiple roles in small clusters.
Code Example
An Elasticsearch index is split into primary shards (for horizontal scale) and each primary is replicated to replica shards (for redundancy and read throughput). Nodes in the cluster host a subset of these shards.
# Inspect cluster health and node layout
curl -s 'http://localhost:9200/_cat/nodes?v'
# name ip heap.percent role master
# node-1 10.0.0.1 45 mdi * ← master + data + ingest
# node-2 10.0.0.2 38 di ← data + ingest
# node-3 10.0.0.3 40 di
// Create index with 3 primary shards × 2 replicas = 9 total shards across nodes
PUT /orders
{
"settings": {
"number_of_shards": 3,
"number_of_replicas": 2,
"refresh_interval": "1s"
},
"mappings": {
"properties": {
"orderId": { "type": "keyword" },
"userId": { "type": "keyword" },
"status": { "type": "keyword" },
"total": { "type": "scaled_float", "scaling_factor": 100 },
"createdAt": { "type": "date" },
"description": { "type": "text", "analyzer": "english" }
}
}
}
// Inspect shard placement
GET /_cat/shards/orders?v
// index shard prirep state node
// orders 0 p STARTED node-1 ← primary 0 on node-1
// orders 0 r STARTED node-2 ← replica of 0 on node-2
// orders 0 r STARTED node-3
// orders 1 p STARTED node-2
// orders 1 r STARTED node-1
// orders 1 r STARTED node-3
// ...
- Number of primary shards is fixed at index creation — plan for ~20-40 GB per shard; splitting later means reindexing. A 600 GB index → ~20 primaries.
- Replicas multiply query throughput (each replica can serve reads) and provide HA — a 3-node cluster with
number_of_replicas: 1survives one node failure without data loss. - Rule of thumb:
total_shards = primaries × (1 + replicas). This index uses 3 × 3 = 9 shards — exactly 3 per node. - A document's shard is
hash(_routing) % number_of_primary_shards; by default_routing = _id. Custom routing lets you co-locate a tenant's documents on one shard to reduce query fan-out. - Master-eligible nodes coordinate cluster state; data nodes hold shards; ingest nodes run pipelines. In small clusters all roles overlap; at scale, separate them.
Common Mistakes & Pitfalls
Setting too many primary shards at index creation (shards are fixed and cannot be changed without reindexing). Elasticsearch recommends 10-50 GB per shard as a target.
Check your understanding
Answer these without looking back at the article.
- What is split-brain in Elasticsearch and how does the quorum mechanism prevent it?
- How do you resize the number of shards on an existing index without downtime?
- What is shard allocation awareness and when would you use it?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.