Why should you care?

A bad key (monotonically increasing _id only) puts all inserts on one hot shard. A good key spreads writes.

See it live — copy this example

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

// Ranged compound key for time-series style access
sh.shardCollection("NoSQLVerse.readings", { deviceId: "hashed" })
// Or ranged:
// sh.shardCollection("NoSQLVerse.orders", { tenantId: 1, orderId: 1 })
db.readings.find({ deviceId: "sensor-42", ts: { $gte: ISODate("2026-07-19") } })

Run Example »

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

What happened?

• Hashed deviceId spreads devices across shards.
• Queries that include deviceId target specific shards.
• orders often use tenantId first so each tenant’s data tends to colocate for targeted queries.

Practice next

1. List your top queries and which fields they always include.
2. Reject keys with <1000 distinct values for large collections.
3. Prefer compound keys that match query patterns.
4. Sketch a key for multi-tenant orders.
5. Explain why status alone is a terrible shard key.

Remember

Shard key partitions documents. Need cardinality + query affinity. Hashed keys spread writes evenly.

IoT deviceId hashing

Millions of sensors write continuously; hashed deviceId avoids a single hot shard.

Outcome: Ingest throughput scales near-linearly with shard count.