When Should You Deploy Dedicated Coordinating Nodes in Elasticsearch?

1. What is a Coordinating Node?

In an Elasticsearch cluster any node can act as a coordinating node, handling HTTP requests for indexing and search.

A dedicated coordinating‑only node (CO) does not store data nor participate in master election; its sole duty is to receive HTTP requests and forward them to other nodes.

It is analogous to a front‑desk receptionist that routes client requests to back‑end services.

2. Advantages of Dedicated Coordinating Nodes

2.1 Reduce load on data and master nodes

Index and search operations consume significant heap, CPU and network resources. If data nodes also handle these requests they can become bottlenecks or unstable. Coordinating nodes strip these tasks, allowing data nodes to focus on shard‑level work.

2.2 Lower request latency

In high‑concurrency scenarios the coordinating node shares the processing pressure, decreasing both maximum and average request latency.

2.3 Simplify client configuration

When the cluster scales, clients only need to address coordinating nodes; load balancers can point to a fixed set of nodes, avoiding frequent client re‑configuration.

3. Request Processing Flow

3.1 Search request

The coordinating node receives the search request, determines which indices to query, and distributes the query to each relevant shard (primary or replica). Each shard returns matching document IDs and relevance scores. The coordinating node merges, sorts, selects top hits, fetches the full documents from the relevant shards, and returns the assembled result to the client.

3.2 Index (write) request

The coordinating node receives the index request (e.g., adding a document) and determines the target primary shard based on the document ID or routing rule.

It forwards the request to the primary shard, which writes the document and replicates it to all replica shards.

For bulk requests the coordinating node repeats the above steps for each document and builds the bulk response.

Both search and bulk indexing consume considerable memory and CPU on the coordinating node, especially when merging large result sets.

4. Cost of Using Dedicated Coordinating Nodes

4.1 Cluster‑state synchronization overhead

Every node, including coordinating nodes, must maintain a copy of the cluster state. Adding coordinating nodes increases the latency of state synchronization, particularly in large clusters.

4.2 Hardware resources

Coordinating nodes require dedicated CPU, heap memory and network bandwidth. Their capacity must be planned to match the expected query and indexing load.

4.3 When to use them

Introduce dedicated coordinating nodes when data nodes suffer memory pressure or instability, when request latency is high, or when the cluster reaches roughly 10‑20 data nodes (the exact number depends on document complexity, query frequency and shard count). However, more coordinating nodes are not always better; excessive numbers can become a new bottleneck.

5. How to Deploy Dedicated Coordinating Nodes

5.1 Determine number and size

Deploy at least two coordinating nodes for redundancy and allocate sufficient memory for result merging and CPU for processing.

5.2 Configure node role

In the node’s elasticsearch.yml set: node.roles: [ ] This makes the node a pure coordinating node.

5.3 Add to the cluster

Deploy the nodes using the same method as other nodes and ensure they successfully join the cluster.

5.4 Adjust client settings

Point HTTP clients to the coordinating nodes, preferably via a load balancer using round‑robin distribution.

5.5 Monitor performance

After deployment, closely monitor CPU usage, heap consumption and request latency of the coordinating nodes to verify they are not becoming a bottleneck.

5.6 Optional routing preference

Use the preference parameter to route requests consistently, e.g.: GET /_search?preference=my-session-id This can improve cache utilization for both coordinating and data nodes.

6. Pitfalls

6.1 Insufficient coordinating nodes

Too few or undersized coordinating nodes can become the new performance bottleneck; size them based on load‑test results.

6.2 Shard routing optimization

Adding a preference parameter can help keep requests on the same shard, leveraging node‑level caches.

7. Summary

Dedicated coordinating nodes are a valuable tool for optimizing large or high‑concurrency Elasticsearch clusters by off‑loading HTTP handling from data nodes, reducing resource contention and improving stability. Their adoption incurs hardware and cluster‑state synchronization costs, so the optimal configuration should be determined through testing and continuous monitoring.