MongoDB Shard Keys Trade Distribution Against Targeted Reads

A shard key determines how documents are distributed and which queries can be targeted. A key that spreads writes well can make an important query scatter across shards; a key that aligns with a common filter can still create a hot shard when one tenant dominates.

Choose the key from observed access patterns and growth, not from a field that merely looks unique.

The concrete problem

Consider a multi-tenant event collection. tenantId is frequently present in queries, while eventId has high cardinality. A compound design may preserve useful targeting while adding distribution within the tenant's range, but the exact choice depends on query shape, cardinality, zone requirements and the deployment's sharding rules.

Figure: Workload filters and skew → Candidate shard-key distribution → Targeted or scatter-gather reads.

A worked example

// Read-only inventory examples; not a production shard command.
db.events.aggregate([
  {$group: {_id: '$tenantId', events: {$sum: 1}}},
  {$sort: {events: -1}},
  {$limit: 20}
]);
db.events.find({tenantId: 't42'})
  .sort({createdAt: -1}).limit(50)
  .explain('executionStats');
// Test candidate keys in a representative isolated sharded topology.

Why the behavior matters

High cardinality provides more distinct key values, but frequency distribution and monotonicity also matter. A timestamp can be highly unique while concentrating new writes at one end of the key space. Hashing changes distribution characteristics but also changes how range queries can be targeted.

Inspect the actual queries: equality on a shard-key prefix, range predicates, sort requirements and operations that omit the key entirely. A scatter-gather query may be acceptable for an occasional administrative task and unacceptable for a high-QPS user endpoint. Classify workloads rather than declaring scatter-gather universally forbidden.

Failure modes and design tradeoffs

The largest tenant can dominate a key that looks balanced when averaging across all tenants. Test skew, not only uniform synthetic data. Consider growth in both number of tenants and per-tenant volume. Unique-index constraints, resharding capabilities and operational limits depend on exact MongoDB version and topology.

A successful resharding feature does not make the initial choice free to reverse. Moving data consumes resources and needs a measured operational plan. Avoid performing key changes merely to satisfy a tutorial demonstration.

What to verify before adoption

Build a small workload matrix covering tenant reads, time-range queries, point lookups and ingestion. Measure targeted shard counts, per-shard write rate and latency under skew. Inspect explain output and distribution tools available in the tested version. Document why the selected compromise fits the application and which growth signal should trigger reevaluation.

Primary reference

• MongoDB documentation. Verify the exact deployed version and driver behavior before using the example in a production runbook.