The Runtime Theory

Shard Routing: From Query to the Right Node

Follow a query as a hash function maps the shard key to a shard, the routing layer connects, and the database node executes the query and merges the results.

The Runtime Theory Team08 stages

trace / request.md

QUERY HITS THEROUTING LAYERSHARD KEYIS EXTRACTEDKEY IS HASHEDHASH MAPSTO A SHARDCONNECTIONTO THE SHARDSHARD EXECUTESLOCALLYKEYLESSQUERIES FAN OUTRESULT RETURNSTO THE CLIENT

readyThe query arrives at a proxy or an application-side client library. The table is partitioned horizontally: every row lives on exactly one shard, each a full independent database.

Sharding moves the routing decision out of a single database and into a hash function. This diagram is the path a query takes: extract the shard key, hash it, map the hash to a node, and execute there. The design goal is that every query carries its key — because the moment it doesn't, the proxy has to ask every shard and merge the answers, which multiplies cost by the number of shards.

The routing scheme is the permanent decision. Modulo routing is simple and terrible to resize — moving from N to N+1 shards remaps almost everything. Consistent hashing keeps most mappings stable but needs a virtual-node layer to stay balanced. The stages after routing — connection pooling, local execution, merge — are the same in any design. This flow is why the shard key choice is the most consequential decision in a sharded system: it determines which of these stages is a point lookup and which is a fan-out.