What makes a good MongoDB shard key, and how do cardinality, frequency and monotonicity affect it?

## What the shard key actually controls In a sharded cluster, one collection's documents are divided into contiguous ranges of shard key values, and each range is owned by exactly one shard. The shard key is the only input to that placement decision. It determines where a document lands, which shards a query must visit, and how evenly write traffic spreads across the cluster. The router process, `mongos`, reads the range-to-shard map from the config servers; a query whose filter carries the shard key can be sent only to the shards owning the matching ranges, while a query without it must be broadcast to all of them. Because placement derives from this one key, a bad choice is not something more hardware, a bigger balancer, or better indexes can repair. ## Cardinality — how finely the space can be divided Cardinality is the number of distinct values the key takes. MongoDB can only cut the key space *between* two distinct values, so cardinality is a hard ceiling on how many pieces the data can be split into. If you shard on a `status` field with five values, the collection can never be divided into more than five indivisible groups no matter how many terabytes it holds or how many shards you add. A range that ends up containing exactly one distinct shard-key value cannot be split at all; if it grows large, it becomes a permanently oversized range that the balancer will not move, and one shard grows without bound. ## Frequency — how evenly documents spread over the values Cardinality alone is not enough. Frequency asks how many documents sit on each distinct value. Consider a `customerId` key in a business where one enterprise account produces 70% of all orders: cardinality is in the millions, but that one value's documents all share a single key value, so they cannot be divided among shards. The result is the same skew a low-cardinality key produces, just concentrated on one value instead of spread over five. In practice you look at the distribution, not just the count: the worst case is the *most frequent* value, because its documents are inseparable. ## Monotonicity — the direction values move over time Ranged sharding assigns ordered, contiguous ranges. The topmost range has an upper bound of `MaxKey` and is owned by exactly one shard. If the shard key increases with every insert — a timestamp, an auto-incrementing counter, or a default `ObjectId`, whose leading bytes encode the creation time — then every new document falls into that top range, and one shard absorbs 100% of the insert load while the rest sit idle. The balancer reacts by continuously migrating ranges off that shard, which costs I/O without fixing the cause. Monotonically *decreasing* keys have the same problem at the bottom of the range. Hashed sharding and non-monotonic compound prefixes are the standard answers. ## Query targeting — the workload half of the decision The first three properties are about the data; the fourth is about your queries. A key that spreads perfectly but never appears in a filter forces every read to fan out to every shard, so cluster-wide read capacity stops scaling with shard count and tail latency becomes the slowest shard's latency. That is why shard key selection starts with a list of the collection's real access patterns, not with the schema. Frequently the best key is a compromise: something coarse that queries always carry, plus something fine that makes ranges splittable. ## Mechanical requirements A few rules constrain the choice regardless of the data. A supporting index must exist: a ranged key needs an index with the shard key as a prefix, and a hashed key needs a hashed index. MongoDB creates it for you when you shard an empty collection, but on a non-empty collection you must build it first. Any unique index on a sharded collection must be prefixed by the shard key, because each shard can only enforce uniqueness over the documents it holds — so you cannot add an arbitrary unique constraint after sharding. Shard key fields are also effectively business-immutable: changing one is possible in currently supported versions, but only inside a transaction or as a retryable write, so schemas that mutate the key field constantly are a bad fit. ## Putting it together For an `orders` collection queried mostly as "all orders for this customer" and occasionally as "this specific order", `{ status: 1 }` fails on cardinality, `{ createdAt: 1 }` fails on monotonicity, and `{ orderId: 1 }` spreads well but leaves customer queries broadcasting. `{ customerId: 1, orderId: 1 }` gives high cardinality, keeps a large customer's documents splittable by the `orderId` suffix, is non-monotonic in its prefix, and lets customer-scoped queries target a narrow set of ranges. That reasoning — access patterns first, then cardinality, frequency and monotonicity — is what an interviewer is listening for.