How does sharding and routing work in Elasticsearch?
How Elasticsearch sharding and routing work — primary vs replica shards, the routing formula and custom routing — with examples and interview answers.
Expected Interview Answer
Sharding splits an Elasticsearch index into smaller pieces called shards that are distributed across nodes, and routing is the formula that decides which shard a document lives in so it can be stored and found deterministically.
Each index has a fixed number of primary shards (set at creation) plus optional replica shards for redundancy and read scaling. When you index a document, Elasticsearch computes shard = hash(_routing) % number_of_primary_shards, where _routing defaults to the document _id; the same formula on read locates the document, and a search without routing fans out to all shards. Because the primary shard count is baked into the routing math, it cannot be changed later without reindexing — custom routing values let you co-locate related documents on one shard for faster, targeted queries.
- Distributes data and load horizontally across nodes
- Replicas add fault tolerance and boost read throughput
- Deterministic routing makes get-by-id a single-shard operation
- Custom routing co-locates related data for faster queries
- Parallel shard execution speeds up large searches
AI Mentor Explanation
A national cricket board splitting players across regional academies is sharding. Each academy is a shard holding part of the talent pool. The rule 'assign a player to an academy by the first letter of their surname' is routing — deterministic, so anyone can find a player instantly. Fix the number of academies up front and you can't easily re-split without moving everyone, exactly as primary shard count is locked at index creation and reshaping needs a full reindex.
Step-by-Step Explanation
Step 1
Choose primary shards at creation
Set number_of_primary_shards when the index is created; it is fixed and drives the routing formula.
Step 2
Index a document
Elasticsearch computes shard = hash(_routing) % primaries, where _routing defaults to the document _id.
Step 3
Store on primary, copy to replicas
The write lands on the chosen primary shard and is replicated to its replica shards for redundancy.
Step 4
Retrieve deterministically
A get-by-id reruns the same routing formula to hit exactly one shard, so lookups are cheap.
Step 5
Search fans out
A query without a routing value scatters to all shards, gathers results, then merges — unless custom routing narrows it.
What Interviewer Expects
- Distinguishes primary shards from replica shards
- States the routing formula hash(_routing) % number_of_primary_shards
- Knows _routing defaults to _id and can be customized
- Explains why primary shard count is immutable after creation
- Understands custom routing co-locates related documents
Common Mistakes
- Thinking you can change primary shard count without reindexing
- Confusing replica shards with primary shards
- Believing every search hits only one shard
- Over-sharding a small index, wasting overhead
- Ignoring that custom routing can cause hot, unbalanced shards
Best Answer (HR Friendly)
“Sharding breaks an Elasticsearch index into smaller pieces spread across servers so it can hold and search huge amounts of data. Routing is the built-in rule that decides which piece each document goes into, so Elasticsearch always knows where to store and find it.”
Code Example
PUT /orders
{
"settings": {
"number_of_shards": 3,
"number_of_replicas": 1
}
}
// Route all of a customer's orders to the same shard
POST /orders/_doc?routing=customer-42
{
"customer_id": "customer-42",
"total": 129.99
}
// Targeted search hits only that one shard
GET /orders/_search?routing=customer-42
{
"query": { "term": { "customer_id": "customer-42" } }
}Follow-up Questions
- Why can't you change the number of primary shards after index creation?
- How do replica shards improve read performance and availability?
- What problems can custom routing introduce?
- How would you reshard an existing index?
- How does Elasticsearch decide which replica serves a read?
MCQ Practice
1. What is the default routing formula for placing a document?
Elasticsearch uses shard = hash(_routing) % number_of_primary_shards, with _routing defaulting to the document _id.
2. Why can't the number of primary shards be changed after index creation?
The primary shard count is part of the routing math, so changing it would relocate documents and requires a full reindex.
3. What is the main purpose of replica shards?
Replicas are copies of primaries that provide fault tolerance and serve read requests to boost throughput.
Flash Cards
What is a primary shard? — A piece of an index that holds a subset of documents; its count is fixed at index creation.
What is the routing formula? — shard = hash(_routing) % number_of_primary_shards, with _routing defaulting to the document _id.
What do replica shards do? — They copy primaries for fault tolerance and serve reads to increase throughput.
Why use custom routing? — To co-locate related documents on one shard so targeted queries hit a single shard.
Continue Learning
Related Interview Questions
What is the difference between a primary shard and a replica shard in Elasticsearch?
medium
How does Elasticsearch handle scaling and cluster health (green, yellow, red)?
medium
What is the role of the coordinating node in an Elasticsearch query?
medium
Why can the same document score differently depending on which shard it lands on, and what does dfs_query_then_fetch do about it?
hard