Analyzing and addressing MongoDB hotspots in a sharded cluster.
Instruction: Describe your approach to identifying and resolving hotspots in a sharded MongoDB cluster to ensure even load distribution.
Updated
Official answer
Compare operation rates and latency across shards, then inspect the key values and query shapes responsible for concentrated work. Distinguish a hot document, hot shard-key value, monotonically growing range, uneven data volume and scatter/gather workload.
Data balancing moves ranges; it does not guarantee equal request load. Splitting or moving a range cannot divide writes to one identical shard-key value across shards. Hashing also maps that same value to the same hash. A manual move may relocate the bottleneck without removing it.
For immediate relief, reduce avoidable reads, bound concurrency or add suitable capacity while preserving correctness. Cache only with a valid freshness/authorization contract. Review zone constraints and migration overhead before moving data.
For a persistent design issue, evaluate supported resharding with a higher-cardinality, less-skewed key that still targets important queries. If changing application data distribution, account for uniqueness, ordering and aggregation costs; arbitrary salting is not free.
Validate using measured key-frequency and workload distributions, including a highly active tenant. Monitor tail latency, migrations and replication during rollout. Use version-appropriate balancing guidance rather than assuming old automatic chunk-splitting behavior still applies.