# Zone sharding and region-aware shard keys > Source-anchored research for Zone sharding and region-aware shard keys. Run status: COMPLETED. Parent: [Shard Key Design and Resharding as Cost Levers](https://llms-explorer.com/tree/shard-key-design-and-resharding-as-cost-levers/) · 5 facets · 18 facts · page: https://llms-explorer.com/tree/zone-sharding-and-region-aware-shard-keys/ ## Structure and components - The documented {country: 1, userid: 1} design uses country for regional zones and userid for higher cardinality and lower value frequency than country alone. A region-only key forfeits that finer distribution component. (low confidence) — [source](https://www.mongodb.com/docs/manual/tutorial/sharding-segmenting-data-by-location/) - In the documented country-prefixed design, including country lets reads target the relevant shard subset; omitting country broadcasts reads. A regional zone can contain multiple shards, so providing only the regional prefix does not guarantee a single-shard query. (medium confidence) — [source](https://www.mongodb.com/docs/manual/tutorial/sharding-segmenting-data-by-location/) ## How it works - Historical bug SERVER-73848 documented conflicting old and new config.tags ranges, or duplicate-key errors, when resharding from a hashed key to the same field without hashing. The issue records fixes in 5.0.19, 6.0.7, 7.0.0-rc3 and 7.1.0-rc0; this is historical upgrade evidence, not proof that current releases retain the defect. (low confidence) — [source](https://jira.mongodb.org/browse/SERVER-73848) - The 2021 University of Piraeus study of spatio-temporal MongoDB workloads used zones to preserve locality and found that fewer nodes processed some queries. Several larger queries became slower because reduced parallelism increased work per participating node; this workload-specific result is not a benchmark of regional deployment costs. (low confidence) — [source](https://openproceedings.org/2021/conf/edbt/p162.pdf) ## Problems, failure modes and limitations - A geographic field must lead the shard key when zones partition directly by geographic location: zone bounds must contain the shard-key prefix and cannot use fields outside the shard key. (medium confidence) — [source](https://www.mongodb.com/docs/manual/core/zone-sharding.md) - Zone ranges include their lower bound and exclude their upper bound, and ranges cannot overlap. Boundary tests should include exact endpoints when validating regional mappings. (medium confidence) — [source](https://www.mongodb.com/docs/manual/core/zone-sharding.md) ## Comparisons and alternatives - Changing zone assignments does not relocate existing data immediately: placement may violate the new policy until balancing completes. Treat the transition as a placement-verification requirement rather than assuming that successful configuration means immediate residency. (medium confidence) — [source](https://www.mongodb.com/docs/manual/core/zone-sharding.md) - A zone can cover multiple country values: MongoDB's location tutorial places both UK and DE in one EU zone. This permits regional resource sharing instead of requiring a separate shard or zone for every country. (low confidence) — [source](https://www.mongodb.com/docs/manual/tutorial/sharding-segmenting-data-by-location/) ## Facts and statements - Zone sharding associates shard-key ranges with one or more eligible shards; a shard may belong to multiple zones. In a balanced cluster, data covered by a zone resides on shards assigned to that zone. (medium confidence) — [source](https://www.mongodb.com/docs/manual/core/zone-sharding.md) - The cost-lever inference is to include the geographic prefix in frequent regional reads and confirm targeting with explain(): avoiding unnecessary cross-shard work can reduce resource demand, but the sources do not provide a general savings percentage. (medium confidence) — [source](https://www.mongodb.com/docs/manual/tutorial/sharding-segmenting-data-by-location/) - The ArchTenet author describes an unnamed production episode in which geo-sharding without region predicates and suitable indexes increased work across shards and increased the database bill. The article labels its pricing illustrative; this is not an independently audited cost benchmark. (low confidence) — [source](https://archtenet.dev/blog/mongodb-geosharding-hidden-cost/) - Documents outside every configured zone range may reside on any shard. Regional placement therefore requires explicit coverage of all relevant geographic values, including newly introduced values. (medium confidence) — [source](https://www.mongodb.com/docs/manual/core/zone-sharding.md) - Defining zones and their ranges before sharding an empty collection enables initial placement consistent with those zones. Changing a populated collection’s zone mapping can require a period of redistribution, so new regional placement is not instantaneous. (medium confidence) — [source](https://www.mongodb.com/docs/manual/core/zone-sharding.md) - Zones determine which shards own a range; they do not alone guarantee that every replica stays in that geography. Atlas Global Cluster documentation describes distributing a zone’s shard members among its configured regions, so residency assessment must also inspect replica-region configuration. (medium confidence) — [source](https://www.mongodb.com/docs/manual/core/zone-sharding.md) - Zones also support assigning selected data to shards with suitable hardware. The cost opportunity is a placement policy matched to workload needs; neither the manual nor Percona’s example establishes a measured total-cost reduction. (medium confidence) — [source](https://www.mongodb.com/docs/manual/core/zone-sharding.md) - Zone ranges must use shard-key fields and include the compound key's prefix. For country-based placement, MongoDB's tutorial uses {country: 1, userid: 1}: country defines geographic groups, while userid contributes higher cardinality and lower frequency than country alone. (medium confidence) — [source](https://www.mongodb.com/docs/manual/core/zone-sharding.md) - Geographic zones can place data closer to the applications that use it, reducing network latency and overhead. This identifies a potential cost lever, but neither cited source quantifies a generally applicable financial saving. (medium confidence) — [source](https://www.mongodb.com/docs/manual/core/zone-sharding.md) - Percona warns that location-based sharding can produce data skew and require additional infrastructure for multi-site deployments. Its guidance recommends monitoring both per-shard data volume and query load; geographic grouping does not itself ensure even resource use. (low confidence) — [source](https://www.percona.com/blog/mongodb-partitioning-best-practices-for-scalability-and-performance/)