In all our previous cluster experiments, we focused mainly on master nodes, data nodes, and role separation, but there is one responsibility that every Elasticsearch node performs silently in the background. This responsibility is called coordination, and it plays a critical role in how distributed search actually works in practice.

Whenever a client sends a request to an Elasticsearch cluster, that request must first land on one specific node. That node becomes responsible for managing the entire request lifecycle, even if it does not contain any of the actual data. It figures out which shards are involved, which nodes hold those shards, how the work should be distributed, and finally how the partial results should be merged into one single response. This behavior is so fundamental to Elasticsearch that it happens automatically and transparently, without us having to configure anything.

Every Node Is a Coordinating Node by Default

One of the most important things to understand is that coordination is not a special role that you enable. Instead, it is a built-in behavior of every node.

• Even if a node is configured as a dedicated master node, it will still coordinate requests if a client sends a request to it. This means that although its primary responsibility is cluster management, it can still accept a search request, forward it to the relevant shards, and merge the results before returning the response.
• Even if a node is configured as a pure data node, it will still coordinate requests when it receives them. In that case, the same node is both executing shard-level queries and also acting as the request manager for the client call.

This explains why, in all our previous demos, we were able to send search requests to any node in the cluster and still get a complete and correct response, even though the data itself was distributed across multiple machines.

What Exactly Does a Coordinating Node Do?

When a request arrives at a node, that node becomes the coordinating node for that request and performs a sequence of well-defined steps.

• First, it analyzes the request and determines which shards need to be queried. In a distributed index, this usually means identifying multiple primary or replica shards across different nodes.
• Then, it sends the request to all those shards in parallel. Each shard executes its part of the query locally and produces a partial result, which might contain documents, scores, or intermediate aggregation data.
• Finally, the coordinating node collects all partial results, merges them, sorts them if required, applies final aggregation logic, and then returns a single combined response to the client.

So, in practical terms, the coordinating node is acting like a distributed query planner and result merger, sitting in front of the rest of the cluster.

How to Create a Coordinating-Only Node

If you want a node to perform only coordination and nothing else, you explicitly remove all roles from it:

node.roles: [ ]

This configuration has a very precise meaning:

• This node is not a master node, so it will never manage cluster state or participate in cluster leadership.
• This node is not a data node, so it will never store shards or hold any index data.
• This node is not an ingest node, so it will never run ingest pipelines.
• As a result, the only thing left for this node to do is coordinate requests.

It is important to understand that this does not disable coordination. In fact, it does the opposite: it forces the node to do only coordination, because all other responsibilities have been removed.

How Such a Node Is Used in a Real Cluster

In a real-world architecture, coordinating-only nodes are usually placed behind a load balancer, and all application traffic is sent to them instead of directly to data nodes.

• The application never talks to data nodes directly. It always talks to coordinating nodes.
• The coordinating nodes distribute the work to the data nodes, collect the results, and return the final response.
• This protects the data nodes from the extra overhead of request parsing, result merging, and aggregation processing, allowing them to focus purely on storage and shard-level execution.