Choose a MongoDB Shard Key From Real Query and Write Distribution

A large collection is sharded on a timestamp because every document has one. Inserts concentrate on the newest range, while queries that lack the key become scatter-gather operations across all shards.

Use the sequence below as a diagnostic method, not as a promise that one setting fits every host; verify its example paths, privileges, and backup assumptions while working to evaluate cardinality, frequency, monotonic growth, targeted queries, zones, and resharding headroom before distributing a MongoDB collection.

Likely failure paths

• The shard key has low cardinality or a small number of values dominate traffic.
• A monotonically increasing range key directs new writes toward one chunk and shard.
• Application queries omit the shard-key prefix, so mongos must broadcast and merge results.

The branches are ordered to protect the strongest evidence around this possibility: the shard key has low cardinality or a small number of values dominate traffic. The observed scope and logs—not a familiar-looking error screen—decide which one applies.

Distributed storage trades one machine’s limits for routing, replication, failover, and consistency decisions; a healthy cluster can still return stale data, scatter a query, or lose an acknowledged write within a documented failure window; in this guide, the practical goal is to evaluate cardinality, frequency, monotonic growth, targeted queries, zones, and resharding headroom before distributing a MongoDB collection.

A controlled investigation

1. Sample production query shapes and measure which include candidate shard keys, including updates and deletes.
2. Calculate candidate cardinality, value frequency, growth direction, chunk distribution, and per-shard operations.
3. Verify a supporting index whose prefix is the proposed key and test targeted versus broadcast explain plans.
4. Budget storage, I/O, CPU, oplog window, and the documented write-block interval before resharding.

The sequence moves from observation toward intervention. Preserve the result of the final check—budget storage, I/O, CPU, oplog window, and the documented write-block interval before resharding—because it provides a useful comparison after the repair.

Make the smallest durable change

1. Prefer a compound or hashed strategy that distributes writes while preserving targeted access for important queries.
2. Use zones only for a stated locality or hardware policy, not as a substitute for balanced keys.
3. Rehearse reshardCollection with production-shaped data and application latency limits before scheduling the live operation.

Before applying “Prefer a compound or hashed strategy that distributes writes while preserving targeted access for important queries,” name its rollback point and the evidence that will count as success. Afterward, repeat the original request and specifically check whether you can observe chunk and operation distribution after representative inserts and queries; a changed symptom at that point is new evidence, not permission to make several more changes at once.

Close the incident with evidence

• Observe chunk and operation distribution after representative inserts and queries.
• Confirm critical queries target the intended shard subset and retain the correct index.
• Test router and shard failures, then verify clients connect through mongos rather than directly to one shard.

One successful refresh is not closure. Keep the incident open until you can also confirm critical queries target the intended shard subset and retain the correct index, adjacent paths have not regressed, temporary diagnostics are gone, and another operator can explain what changed.

Prepare a useful escalation if the boundary is outside your control

Record topology, versions, consistency settings, request or transaction identity, routing key, replication position, failure timeline, and recovery objective; test promotion and reconfiguration with production-shaped data before relying on them during an outage; include the result of this first observation: sample production query shapes and measure which include candidate shard keys, including updates and deletes.

State what was tested, including the result of “Sample production query shapes and measure which include candidate shard keys, including updates and deletes,” and what changed between attempts; evidence tied to that observation is safer and more actionable than granting broad access or sending an unnecessary full database export.

use game
db.events.createIndex({ tenantId: 1, playerId: "hashed" })
sh.shardCollection("game.events", { tenantId: 1, playerId: "hashed" })

db.events.find({ tenantId: "t-42", playerId: "p-9" })
  .explain("executionStats")

Do not trade visibility for a green screen

• Do not shard a small dataset merely because horizontal scaling may be needed later.
• Do not choose a key from schema appearance without measuring real query routing and hot values.

Primary references

• MongoDB sharding manual — official reference consulted for this guide.
• MongoDB reshardCollection — official reference consulted for this guide.

Editorial note: The scenario above illustrates how to approach “Prefer a compound or hashed strategy that distributes writes while preserving targeted access for important queries”; it is a documented example, not a claim about a reader’s server, so verify the cited documentation, take the appropriate backup, and follow the real environment’s access and change-control rules.