Why should you care?

A user in Bengaluru should not always round-trip to Virginia. Latency and data residency laws push global topologies.

See it live — copy this example

Open mongosh or MongoDB Compass, select database nosqlverse, then run the example. Change one field and run again.

// Zone sharding sketch (sharded cluster)
sh.addShardToZone("shardIndia", "IN")
sh.addShardToZone("shardEU", "EU")
sh.updateZoneKeyRange("NoSQLVerse.users", { region: "IN", userId: MinKey }, { region: "IN", userId: MaxKey }, "IN")
db.users.insertOne({ region: "IN", userId: "u1", name: "Ravi" })
db.users.find({ region: "IN", userId: "u1" })

Run Example »

Edit the code below and click Run to see the result in Toolliyo’s live editor.

What happened?

• Shards are tagged to zones IN and EU.
• A key range for region IN pins Indian users to Indian shards.
• Queries that include region become targeted and local.
• Omitting region may scatter.

Practice next

1. Read Atlas Global Cluster docs for your tier.
2. Add a region field to user documents in design.
3. Ensure queries include the location prefix of the shard key.
4. Design a shard key { country: 1, userId: 1 }.
5. List residency constraints for your product.

Remember

Global clusters keep data near users. Zones map key ranges to regions. Query with the location field.

GDPR + India residency

EU customer PII stays on EU shards; Indian data on IN shards.

Outcome: Latency improves and residency auditors are satisfied.