In this short tutorial, we will clearly and systematically understand how Elasticsearch decides where a document is stored and how it is retrieved, even when an index is split into multiple shards across many nodes.
This concept is known as routing, and it is one of the most important internal mechanisms that allows Elasticsearch to scale horizontally while keeping the developer experience simple.

The Problem We Are Trying to Solve

• When an index is split into multiple shards, a natural question arises about data placement.
  If we have an index such as products with four primary shards and we are storing millions of product documents, we must decide how these documents are distributed among those shards so that load is balanced and lookups remain efficient.
• From a developer’s point of view, it is not practical to manually choose shards.
  Developers should not need to know which shard stores which document, nor should applications act like load balancers that manually route requests to specific machines.
• Elasticsearch solves this problem internally using routing logic.
  This design ensures that applications interact only with the index name, while Elasticsearch transparently decides where the data should live.

Developers Do Not Interact with Shards Directly

• Sharding is an internal Elasticsearch mechanism, not an application-level concern.
  While Elasticsearch exposes shard information for monitoring and debugging, applications never directly send requests to shard 0, shard 1, or shard 2.
• All requests are sent to the index, not to individual shards.
  For example, when storing a product, we send a request to the products index without mentioning any shard information at all.
• Elasticsearch automatically figures out the correct shard behind the scenes.
  This abstraction is intentional and allows applications to remain simple even as the cluster grows in size and complexity.

Sending a Request to the Elasticsearch Cluster

• An Elasticsearch cluster is simply a collection of nodes that are aware of each other.
  Each node knows which shards exist and which nodes currently hold those shards, even if it does not store the data itself.
• You can send a request to any node in the cluster.
  It does not matter whether that node holds the relevant shard or not; the cluster coordination layer ensures the request is forwarded correctly.
• The node that receives the request acts as a coordinator.
  This coordinating node determines where the request should go, forwards it to the correct shard-holding node, waits for the response, and then returns the result to the client.

How Elasticsearch Decides the Target Shard (Routing Logic)

• Elasticsearch uses a deterministic routing algorithm to choose the shard.
  This ensures that the same document ID always maps to the same shard, which is critical for fast reads and updates.
• By default, the routing key is the document ID.
  If you do not explicitly specify a routing value, Elasticsearch automatically uses the document’s _id.
• The routing decision follows a simple two-step process.
  First, Elasticsearch computes a hash of the routing key. Second, it applies a modulo operation using the number of primary shards.

Conceptual Example

• Suppose the document ID is ABCD.
• Elasticsearch passes ABCD to a hash function (conceptually similar to a Java hashCode()).
• Assume the hash function returns 41.
• If the index has 4 primary shards, Elasticsearch computes 41 mod 4.
• The result is 1, so the document is stored in primary shard 1.
• The same logic is reused when retrieving the document.
  When you request document ABCD, Elasticsearch performs the same calculation and directly queries shard 1 instead of searching the entire index.

Why This Routing Strategy Is Powerful

• Single-document lookups are extremely efficient.
  Because Elasticsearch knows exactly which shard contains the document, it can avoid unnecessary network calls to other shards.
• The distribution of data is balanced automatically.
  A good hash function ensures that documents are spread evenly across shards, preventing hotspots.
• Applications remain completely unaware of cluster topology.
  You can add or remove nodes without changing application code, as long as shard configuration is handled correctly.

What Happens When There Is No Document ID? (Search Queries)

• Search queries usually do not include a document ID.
  For example, searching for "Apple iPhone" does not provide Elasticsearch with a routing key.
• In this case, Elasticsearch follows the scatter–gather pattern.
  The coordinating node sends the search request to all primary shards, because any shard might contain matching documents.
• Each shard executes the query independently.
  Every shard searches only its local data and returns partial results.
• The coordinating node gathers and merges the results.
  It combines scores, sorts results, applies pagination, and returns a single unified response to the client.

High-Level Summary of Routing Behavior

• Indexing or fetching a document by ID uses deterministic routing to a single shard.
  This makes CRUD operations fast and predictable.
• Search operations without an ID are broadcast to all shards.
  This ensures correctness while leveraging parallel execution across shards.
• Developers interact only with the index name, not shards or nodes.
  Elasticsearch handles routing, coordination, and data distribution automatically.