src/sharding/router.rs/rebalancer.rs use fnv1a_shard(&creator_username, num_shards) to deterministically map a creator to a shard — this reads like plain hash(key) % num_shards rather than consistent hashing (e.g. rendezvous hashing or a hash ring). With plain modulo sharding, changing num_shards (adding capacity) reassigns the shard for the majority of existing keys, not just a proportional fraction — meaning every capacity change requires migrating close to 100% of data rather than the ~1/new_num_shards a consistent-hashing scheme would require. Given this codebase already has a ShardRebalancer built specifically to move data between shards, it's worth confirming whether that machinery is actually sized for "rebalance an imbalanced fixed-N-shard cluster" (its apparent purpose, per RebalanceReport) or would also have to double as "migrate ~100% of data on any shard-count change," which is a much bigger and more disruptive operation that the current design may not obviously support online.
Task: Document whether num_shards is expected to ever change post-deployment. If yes, evaluate switching to a consistent-hashing scheme to bound the migration cost of capacity changes; if num_shards is meant to be fixed forever, document that constraint explicitly since it's a significant operational limitation that isn't otherwise stated anywhere obvious in the sharding module.
src/sharding/router.rs/rebalancer.rsusefnv1a_shard(&creator_username, num_shards)to deterministically map a creator to a shard — this reads like plainhash(key) % num_shardsrather than consistent hashing (e.g. rendezvous hashing or a hash ring). With plain modulo sharding, changingnum_shards(adding capacity) reassigns the shard for the majority of existing keys, not just a proportional fraction — meaning every capacity change requires migrating close to 100% of data rather than the ~1/new_num_shardsa consistent-hashing scheme would require. Given this codebase already has aShardRebalancerbuilt specifically to move data between shards, it's worth confirming whether that machinery is actually sized for "rebalance an imbalanced fixed-N-shard cluster" (its apparent purpose, perRebalanceReport) or would also have to double as "migrate ~100% of data on any shard-count change," which is a much bigger and more disruptive operation that the current design may not obviously support online.Task: Document whether
num_shardsis expected to ever change post-deployment. If yes, evaluate switching to a consistent-hashing scheme to bound the migration cost of capacity changes; ifnum_shardsis meant to be fixed forever, document that constraint explicitly since it's a significant operational limitation that isn't otherwise stated anywhere obvious in the sharding module.