Request Routing — Finding the Shard, Surviving a Move Diagram

Three Ways to Reach the Right Node

Send requests to any node, which forwards them to the owner and relays the reply
Use a routing tier — a shard-aware load balancer that handles no requests itself
Make clients shard-aware so they connect to the owner directly

Who Keeps the Shard Map?

A coordination service like ZooKeeper or etcd holds the authoritative assignment and notifies subscribers on change
HBase and SolrCloud use ZooKeeper; Kubernetes uses etcd; MongoDB uses config servers and mongos
Kafka, YugabyteDB, TiDB, and ScyllaDB run Raft internally for the same job
Riak gossips cluster state instead — weaker, with possible split brain, which leaderless designs tolerate

Hard Questions

If the coordinator fails over, how do you stop two coordinators making contradictory assignments (split brain)?
During a move there is a cutover window: the new owner has taken over while requests to the old one are still in flight
Client-facing node addresses change slowly, so DNS is usually enough
Analytical queries fan out over many shards in parallel — a different execution problem