Choosing a good shard key and avoiding hot spots

WHAT THIS TESTS The interviewer wants to know if you understand that a shard key controls both data distribution and query routing, and why monotonic keys defeat horizontal scaling for writes.

A GOOD ANSWER COVERS Three properties of a good key. High cardinality so the data can split into many chunks. Low frequency, meaning no single value holds a huge share of documents, otherwise that chunk cannot split. Even and non-monotonic write distribution so inserts spread across shards. Plus query alignment: the key should appear in your common query filters so reads route to a single shard rather than broadcasting to all of them.

WHY MONOTONIC KEYS HURT With range-based sharding, the shard owning the top range always holds the maximum value. A timestamp or auto-increment ID means every new insert has the largest value, so all writes land on that one shard. It becomes a hot spot bottlenecking throughput while the rest of the cluster sits idle, and the balancer constantly migrates chunks off it, adding overhead.

LIKELY FOLLOW-UPS How does hashed sharding fix monotonic keys, what tradeoff does hashing impose on range queries, what is a compound shard key, and how do you reshard a poorly chosen key.

ONE CONCRETE EXAMPLE Sharding an events collection on insertion timestamp sends today's entire write load to one shard. Switching to a hashed shard key or a compound key like userId plus timestamp scatters writes evenly, though a pure hash sacrifices efficient range scans over time.