Sharding: Architecture, Shard Keys, and the Balancer
What this domain covers
Sharding: Architecture, Shard Keys, and the Balancer tests your ability to design a sharded cluster, choose a shard key for query and write patterns, and operate chunk migration.
Core rules
- A sharded cluster has mongos routers, a config server replica set, and shard replica sets. mongos caches routing metadata and refreshes it; clients connect to mongos, not to shards directly.
- The shard key must exist in every document and be indexed. It is immutable in older versions; MongoDB 4.4 added shard key refinement and 5.0 added resharding, but planning still matters.
- High cardinality and low frequency are key. Monotonically increasing keys concentrate inserts on the max chunk. Hashed keys spread writes but make range queries scatter-gather.
- Default chunk size is 128 MB. The balancer moves chunks; use zones for data placement and balancer windows for control.
- Targeted queries include the shard key; scatter-gather queries go to all shards.
Worked example
An orders collection uses an ObjectId order_id and inserts are monotonic. A ranged shard key on order_id sends all new inserts to the last chunk, creating a hotspot. A hashed shard key on order_id distributes writes, but queries by order_id become scatter-gather unless they include the hashed field. For a multi-tenant app, a compound key of tenant_id and created_at gives targeted tenant queries and range locality; hashing tenant_id would spread a large tenant across shards.
Traps
Choosing a low-cardinality key such as status; assuming hashed keys support efficient range scans; sharding after loading data without planning; leaving jumbo chunks; and forgetting the balancer when restoring.