Coordinating node with writes and reads by ID

[Andy0708]

Hello,

I have a question related to coordinating nodes. I understand the purpose of coordinating nodes, at least in regards to search queries and bulk indexing. However, I am unsure how things work with writes and reads (by ID).

There will of course always be a node that receives the API request from the client, which will be the coordinating node. This also applies for write and read requests. My doubt is how the communication works from here, after routing is done. For instance, after a read request for document 123 is routed to a primary or replica shard, is the coordinating node still responsible for sending the response to the client, or is the request forwarded to the appropriate shard, which then responds to the client? Basically I am wondering if the node that received the query in the first place (the coordinating node) will always be the one responding to the client. That is true for search requests, for instance, but is it also the case for reads by ID and writes?

My guess would be that the coordinating node will always be responsible for responding to the client. Could someone confirm whether or not this assumption is true?

Thanks in advance!

[Andy0708]

Bump

[spinscale (Alexander Reelsen)]

Confirmed your assumption.

The node that receives the TCP connection is the one responsible for sending the response to the client. No matter if it is a read or a write request, a search or a get-by-id request, the coordinating node will forward the request internally without ever telling the client where something is forwarded to, as this is considered internal information.

hope this helps!

--Alex

[Andy0708]

Excellent, thank you! That makes sense that the coordinating node always responds to the client. Just wanted to confirm. Thanks!