Shard key
The column that determines which shard (database node) a row lands on in a horizontally partitioned database. The choice of shard key is one of the most important — and hardest to change — decisions in a distributed database.
Mechanic: the key's value is hashed or range-mapped → determines the shard. Goal: even data distribution AND having the most common queries hit a single shard (avoiding expensive "cross-shard" queries). Classic traps: a bad key creates "hotspots" (one shard gets all the traffic — e.g. sharding on date when all new traffic is "today"), or forces queries to ask all shards (scatter-gather). A good key: high cardinality, even access, matches the query patterns (e.g. tenant ID in multi-tenant). Hard to change after the fact → often requires a full resharding. Related: hash vs range sharding, and "co-location" (put related rows on the same shard). Central in systems like Vitess, Citus, MongoDB, DynamoDB.