# Does Elasticsearch clients try to request to the node that has the primary shard of a specific doc?

**URL:** <https://discuss.elastic.co/t/does-elasticsearch-clients-try-to-request-to-the-node-that-has-the-primary-shard-of-a-specific-doc/350181>\
**Category:** Elasticsearch\
**Created:** [January 1, 2024, 2:51pm UTC](https://discuss.elastic.co/t/does-elasticsearch-clients-try-to-request-to-the-node-that-has-the-primary-shard-of-a-specific-doc/350181 "2024-01-01T14:51:04Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![AmirrezaRiahi](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/amirrezariahi/32/130412_2.png) [@AmirrezaRiahi](https://discuss.elastic.co/u/AmirrezaRiahi)\
**Post date:** [January 1, 2024, 2:51pm UTC](https://discuss.elastic.co/t/does-elasticsearch-clients-try-to-request-to-the-node-that-has-the-primary-shard-of-a-specific-doc/350181/1 "2024-01-01T14:51:04Z")

</div>

From my understanding, nodes only can perform write operations on documents if they own their primary shard. Therefore if we have 2 nodes `A`, `B` and `A` owns the primary shard of the doc `D`, if the client asks node `B` to modify document `D`, node `B` will route the requests to node `A` which is the owner or `D`'s primary shard. Obviously it would be better for the client to directly request to the node which is owner the primary shard of a specific document to perform write operations. My question is that whether common Elasticsearch clients (Kibana, python, etc) try to utilize this fact to make their requests more performant?

---

<div class="post-metadata">

**Author:** ![Christian\_Dahlqvist](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/christian_dahlqvist/32/4617_2.png) [@Christian\_Dahlqvist](https://discuss.elastic.co/u/Christian_Dahlqvist)\
**Post date:** [January 1, 2024, 3:11pm UTC](https://discuss.elastic.co/t/does-elasticsearch-clients-try-to-request-to-the-node-that-has-the-primary-shard-of-a-specific-doc/350181/2 "2024-01-01T15:11:45Z")

</div>

No, I do not believe they do. Elasticsearch can relocate shards at any point so this would add a lot of complexity for little gain. A lot of the time indexing is also done through bulk requests, which could target multiple shards spread across the cluster where this type of request routing would not be beneficial.

---

<div class="post-metadata">

**Author:** ![AmirrezaRiahi](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/amirrezariahi/32/130412_2.png) [@AmirrezaRiahi](https://discuss.elastic.co/u/AmirrezaRiahi)\
**Post date:** [January 1, 2024, 3:28pm UTC](https://discuss.elastic.co/t/does-elasticsearch-clients-try-to-request-to-the-node-that-has-the-primary-shard-of-a-specific-doc/350181/3 "2024-01-01T15:28:01Z")

</div>

Thanks for your reply. So the client can determine primary shard of the document but can not determine the node which has the shard, right?

---

<div class="post-metadata">

**Author:** ![Christian\_Dahlqvist](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/christian_dahlqvist/32/4617_2.png) [@Christian\_Dahlqvist](https://discuss.elastic.co/u/Christian_Dahlqvist)\
**Post date:** [January 1, 2024, 3:49pm UTC](https://discuss.elastic.co/t/does-elasticsearch-clients-try-to-request-to-the-node-that-has-the-primary-shard-of-a-specific-doc/350181/4 "2024-01-01T15:49:50Z")

</div>

The client does not care/know how many shards an index have or where they are located. This is handled by the node receiving the request. A client can send an index request to an index that does not yet exist and have it created automatically.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [January 29, 2024, 3:50pm UTC](https://discuss.elastic.co/t/does-elasticsearch-clients-try-to-request-to-the-node-that-has-the-primary-shard-of-a-specific-doc/350181/5 "2024-01-29T15:50:38Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.
