Should have high distinct values (e.g., user_id, email)
Avoid low-cardinality fields (e.g., boolean, gender)
The shard key should ensure that data is evenly distributed across all shards to prevent any one shard from becoming overloaded. High cardinality fields (fields with many unique values) are often good candidates
In MongoDB, shard key values are immutable. Once set, they cannot be updated, so choose a key that won't require modifications.
We have a new collection that stores user profiles and we need to shard it. Which field would you pick as the shard key and why?
If you choose a shard key that has only a few distinct values, what immediate problem might you see in the cluster?
Our product team wants to add a feature that queries orders by status and date range. How would you evaluate whether to include status, date, or a compound key as the shard key?
During a load test you notice one shard receiving 70% of the writes. Walk me through how you would diagnose whether the shard key choice is the cause.
You inherit a legacy sharded cluster where the current shard key is an auto‑incrementing orderId and you’re seeing severe write hotspots. Design a migration plan to a better shard key without downtime.
Explain how you would balance the need for efficient range queries against the risk of uneven chunk splits when picking a compound shard key for a time‑series dataset.
Across multiple services we share a common MongoDB cluster. How would you create a shard key strategy that supports independent service growth while minimizing cross‑service impact on chunk migrations?
Consider a scenario where regulatory requirements force you to relocate data for a specific region. How does your shard key choice affect the ability to move that subset of data, and what architectural safeguards would you put in place?