MongoDB Sharding: Shard Keys, Chunks, Balancer, Zones
Fast recall
Quick revision
Core answer
reshardCollection (5.0+) fixes online.Whether you understand the cluster topology, the shard-key contract, and the operational realities of sharded MongoDB
Picking a monotonic or low-cardinality shard key, assuming sharding adds free scale without access-pattern discipline
Discuss `reshardCollection`, hashed vs compound keys, jumbo chunks, zones, targeted vs scatter-gather, and the role of config servers
Interview-ready guide
Interview answer
Describe the topology
- Shards (replica sets), config servers,
mongosrouters mongosis stateless and pulls metadata from config servers
Explain the shard key
- Field(s) that decide which shard owns each document
- Good = high cardinality, low frequency, non-monotonic, query-aligned
- Bad = monotonic (ObjectId), low-cardinality, whale values
Cover chunks and balancer
- Chunks 128MB ranges or hashed buckets
- Balancer moves chunks to keep distribution even
- Pause per collection during sensitive ops
Describe routing
- Targeted query = one shard, fast
- Scatter-gather = every shard, slow — design queries to include the shard key
Mention zones and resharding
- Zones pin key ranges to shards for residency or whale isolation
reshardCollection(5.0+) changes the shard key online
Close with advice
- Don't shard prematurely — vertical scale goes far
- Test shard distribution with production-scale data before going live
MongoDB Sharding: Shard Keys, Chunks, Balancer, Zones
Direct Answer
MongoDB sharding partitions a collection across shards by the shard key. Data is split into chunks (default 128MB ranges or hashed buckets); the balancer moves chunks between shards to keep distribution even. mongos routers pull metadata from config servers and route each query to the right shard(s) — queries including the shard key are targeted (one shard); those without it scatter-gather across all shards. Zones pin ranges to specific shards for data residency or whale isolation. The shard key choice decides everything — high cardinality, low frequency, non-monotonic (or hashed), query-aligned — and bad choices cause the classic hot-shard failure mode that reshardCollection (5.0+) fixes online.
Common Mistakes & Pitfalls
Picking a monotonic or low-cardinality shard key, assuming sharding adds free scale without access-pattern discipline
Check your understanding
Answer these without looking back at the article.
- What happens to writes during a chunk migration?
- How does `reshardCollection` keep data consistent during the change?
- When does a compound + hashed shard key beat pure hashed?
- How do zones interact with balancer decisions?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.