Shard key design that spreads writes instead of concentrating them

Overview

A freight tracking platform had sharded its largest collection on a timestamp-derived key. Every insert landed in the same chunk range, so one shard absorbed the entire write load while the others idled. Several chunks had also grown past the split threshold on low-cardinality values and were stuck as jumbo chunks the balancer refused to move.

Challenge

Reshaping a shard key on a live multi-terabyte collection is not a configuration change. The engagement had to produce a key that distributed writes, still supported the platform's dominant query patterns without scatter-gather, and could be adopted through a migration path that did not require an extended maintenance window.

Environment

Sharded MongoDB cluster spanning on-premises hardware and cloud capacity, backing shipment tracking and telemetry.

Approach

AceMQ profiled the real query mix from the slow query log and application code rather than the documented access patterns, which had drifted. Candidate keys were evaluated against write distribution, targeted-versus-broadcast query ratio, and chunk cardinality, then validated on a restored copy of production before any change was proposed.

Solution

• Profiled actual query shapes and write distribution per shard to establish the real access pattern, not the documented one
• Evaluated candidate compound and hashed shard keys against write spread, query targeting, and chunk cardinality
• Validated the recommended key on a restored production-scale copy before committing to a plan
• Designed a phased migration using resharding with defined checkpoints and a rollback position at each stage
• Resolved existing jumbo chunks and corrected the zone configuration that had pinned ranges to the wrong shards
• Documented balancer windows and chunk size settings aligned to the platform's ingest profile

Outcome

Technologies