That’s not exactly how it works. The
ShardCoordinator is not a hub where everything has to go through.
Instead, this is what will happen:
Imagine a 3-node (A, B, C) cluster each hosting 2 shard regions (A1, A2, B1, B2, C1, C2).
When node C gets a message that is supposed to go to shard B2, it will first ask the
ShardCoordinator where it can find B2. It won’t send the message to the coordinator to get it dispatched to the right location. If will ask for the location instead.
After that first call, subsequent messages arriving in C and targeting B2 won’t need a round trip to the
ShardCoordinator, because C now knows where B2 lives. After a while, all nodes will know where are all the shards.
Now, that was the situation in the past. Since the introduction of
ddata, the shard information is automatically shared between the nodes using a CRDT. In that case, when C become part of a cluster it almost immediately gets to know the shard locations.
And when we have a shard re-distribution, for instance, when a node is removed and its shard regions are moved to other nodes, that information is also propagated to all remaining nodes via the CRDTs.
UPDATE: as @patriknw mentioned below, the
ShardCoordinator still need to be contacted whenever the location of an entity is unknown, also when using