141: MongoDB Sharding and Horizontal Scaling — Shard Keys, Chunks/Ranges, `mongos`, Balancing, Zones, and Hotspots

Learning objectives

You will learn to:

understand when sharding is needed;
understand sharded-cluster components;
choose shard keys from workload;
distinguish ranged and hashed sharding;
understand targeted versus scatter-gather queries;
understand chunk/range balancing;
understand zones;
understand hot shards;
understand monotonic keys;
understand unique index/shard-key interactions at a practical level;
understand resharding;
understand transactions across shards;
avoid sharding too early.

Scale vertically first?

Many applications can scale for years on:

text
one replica set
strong indexes
good modeling
proper hardware

Sharding introduces distributed-system complexity.

Do not shard because “Mongo is for sharding.”

Shard when concrete requirements exceed practical single-replica-set capacity or distribution needs.

Sharded cluster components

Conceptually:

text
client
  ↓
mongos routers
  ↓
config server replica set
  ↓
shard A replica set
shard B replica set
shard C replica set

Each shard typically is replica set.

Config servers store cluster metadata.

mongos routes operations.

Managed Atlas abstracts much of operation.

Shard key

Shard key determines document distribution/routing.

This is one of the most important irreversible-ish architecture decisions, though modern Mongo supports resharding.

Good key should consider:

cardinality;
write distribution;
query targeting;
growth;
monotonicity;
tenant distribution;
future scale.

No universal perfect key.

Example tenant workload

Documents:

javascript
{
  tenantId,
  orderId,
  createdAt,
  ...
}

Queries nearly always:

text
tenantId = ?

Potential shard key:

javascript
{
  tenantId: 1
}

Problem:

One giant tenant can dominate one shard.

Alternative compound/hashed strategies may distribute within tenant but affect query targeting.

Choose based on actual tenant sizes/workloads.

Ranged sharding

Documents partitioned by ranges of shard-key values.

Example:

text
A-M → shard 1
N-Z → shard 2

Good for range queries on shard key.

Can hotspot on monotonic keys.

Hashed sharding

Mongo hashes shard-key value for distribution.

Good for even distribution.

Poor for range locality because adjacent original values spread across shards.

Equality queries can target.

Monotonic key hotspot

Shard key:

javascript
{
  createdAt: 1
}

All new writes go to latest range/shard until split/movement.

Creates hot shard.

Hashed time/compound design can distribute, but then time-range targeting changes.

Do not shard on timestamp alone for high write ingestion without considering hotspot.

Cardinality

Low-cardinality shard key:

text
status ∈ {open,done}

cannot distribute data well.

Need enough distinct values/ranges.

Frequency distribution

High cardinality is not enough if one value dominates 80% writes.

Example tenant megaCorp.

Analyze distribution.

Query targeting

Query includes full shard key equality:

javascript
{
  tenantId: X
}

router can target shard(s).

Query missing shard key:

javascript
{
  email: "..."
}

may scatter to all shards.

Scatter-gather increases latency/load.

Critical API queries should include shard key or be otherwise designed/indexed.

Shard key and multi-tenancy

A tenant key can provide data locality and routing.

But one large tenant may need finer distribution.

Compound:

javascript
{
  tenantId: 1,
  entityId: "hashed"
}

conceptually distributes within tenant while preserving tenant prefix behavior according to Mongo's supported shard key definitions/version.

Check current docs for exact hashed compound constraints.

Chunks/ranges

Mongo partitions shard-key space into ranges and distributes.

Modern terminology/implementation evolves; cluster balancer migrates ranges.

Application should not depend on a specific document living on one shard forever unless zone design.

Balancer

Balancer redistributes data to maintain balance.

Migrations use network/disk/CPU.

Heavy balancing can affect workload.

Monitor.

Do not run enormous sharding changes just before peak traffic without plan.

Zones

Assign shard-key ranges to specific shards.

Use cases:

data residency;
regional locality;
hardware tiers.

Example:

text
EU tenants → EU zone
JP tenants → Japan zone

Architecture must still handle failover/compliance.

Zones complicate capacity.

Hashed `_id`

Using hashed _id can distribute writes.

But queries by another tenant/status field may scatter.

Shard key must support dominant query patterns, not only write balance.

Compound shard key

Useful to combine:

text
tenant routing
+
distribution

Example design decision:

javascript
{
  tenantId: 1,
  orderId: 1
}

versus:

javascript
{
  tenantId: 1,
  orderId: "hashed"
}

Evaluate:

list orders by tenant;
point get by tenant+order;
write distribution;
giant tenants;
zone needs.

Global indexes concept

Traditional sharded queries often require shard key for targeted uniqueness/routing.

MongoDB capabilities evolve; check current version features for global indexing/unique constraints.

Do not assume a unique index on field not containing shard key works cluster-wide under all versions/configurations.

Verify MongoDB 8.3 docs.

Unique constraints

Sharded unique index rules differ from non-sharded.

Design global business uniqueness:

text
email unique per tenant
external event ID

with shard key/collection strategy.

Do not discover constraint limitation after sharding production.

Scatter-gather

Query:

javascript
{
  status: "open"
}

on cluster sharded by tenant can hit every shard.

If endpoint is admin global dashboard rarely used, maybe acceptable.

If hot endpoint, redesign:

include tenant;
materialized global summary;
secondary analytics system.

Aggregation on sharded cluster

Pipeline stages can execute partially on shards then merge.

$lookup, $group, $sort can involve network/merge cost.

Explain on sharded topology.

Do not extrapolate single-node pipeline performance.

Cross-shard transaction

Supported but adds coordination.

If transaction frequently touches many shards, latency/availability cost rises.

Shard key should try co-locate transactionally related data where possible.

Shard-key updates

Updating shard-key fields has special behavior/constraints and can cause document movement.

Treat shard key as stable domain identity where possible.

Resharding

Modern MongoDB supports resharding collections.

Still a major operation:

capacity;
duration;
oplog/change traffic;
index readiness;
application compatibility.

Design key carefully from start, but know mistakes can be corrected with operational cost.

Refine shard key

Mongo supports refining shard keys in supported versions to add suffix fields without full reshard in certain cases.

Useful as workload evolves.

Check current requirements.

Hot shard monitoring

Track per-shard:

text
ops/sec
CPU
disk
cache
network
storage
chunk/range distribution
connections
latency

Balanced data size does not guarantee balanced load.

One tenant may drive all reads.

Jumbo ranges/documents

Large ranges that cannot split/migrate under constraints can complicate balancing.

Avoid extremely low-cardinality/unsplittable keys.

Sharding and indexes

Shard key index requirements.

Every shard also needs secondary indexes for local query patterns.

Index count multiplies storage/write cost across cluster.

Sharding and backup

Backup must capture consistent distributed cluster metadata/data.

Use Atlas backup or supported sharded backup procedures.

mongodump across huge cluster is not automatically ideal disaster-recovery solution.

Sharding and connection strings

Application connects to mongos/Atlas endpoint, not individual shard directly.

Driver performs topology.

Do not bypass router for normal app operations.

Capacity planning

Adding shards does not instantly make every query faster.

If bottleneck is:

unindexed scan on every shard;
giant scatter-gather;
application CPU;
network;
one hot key;

more shards may worsen coordination.

Fix query/model first.

Failure clinic

shard too early;
timestamp shard key hotspot;
low-cardinality key;
giant tenant hotspot;
critical query missing shard key;
assume even data = even load;
unique index rules ignored;
every transaction cross-shard;
global analytics scans online cluster constantly;
no capacity for balancing/resharding;
connect directly to shard.

Exercises

Design shard key for multi-tenant orders.
Compare ranged vs hashed for time-series writes.
Identify scatter-gather queries.
Model giant-tenant hotspot.
Design zone sharding for residency.
Evaluate compound shard key.
Explain unique constraint implications.
Design materialized global dashboard to avoid scatter.
Simulate reshard decision.
Create monitoring dashboard dimensions per shard.

Mastery checklist

Explain:

sharded components;
shard key;
cardinality/frequency;
ranged/hashed;
targeting;
scatter-gather;
hot shard;
balancing/zones;
unique-index implications;
cross-shard transactions;
reshard/refine;
why sharding is not first optimization.