Large-Scale Database Design

Introduction

Large-scale database design begins where a single replica set stops being enough — typically multi-TB working sets, 100k+ writes/sec, multi-region read traffic, or hard residency rules. At that scale the design choices that worked at small scale (single collection, unrestricted queries, embedded everything) start to actively work against you.

This lesson distills the patterns that consistently survive contact with very large MongoDB deployments.

Understanding the topic

Patterns that scale to petabytes:

• Pick the shard key like a marriage. Hashed for write distribution; ranged for locality; never monotonic.
• Bucket high-cardinality time data. Time-series collections beat one-doc-per-event 10×.
• Embed for reads, reference for unbounded growth. Order line items embed; comments on a blog post reference.
• Pre-aggregate analytics. Never re-scan the firehose; build rollups via $merge.
• Zone sharding for residency. Pin data to the region of the user who owns it.
• Tier storage. Online Archive moves cold data to S3 at 90%+ cost savings.
• Capacity headroom ≥ 30%. Auto-scaling is a safety net, not a strategy.

Syntax reference

Shard key cheat sheet:

Workload                                 Good shard key                Why
─────────────────────────────────────────────────────────────────────────────
Multi-tenant SaaS                       { tenantId: "hashed" }        Even write spread
IoT / time-series                       { device:"hashed", ts:1 }     Locality + spread
Social feed                             { userId:"hashed" }           User shards co-locate
Catalog                                 { categoryId:1, sku:1 }        Range queries by category
Geo data                                 { region:1, _id:"hashed" }    Zone-sharded residency
ANTI-PATTERN                             { createdAt: 1 }              Monotonic = hot shard

Real-world use

Coinbase shards trades by user-hash + symbol; Sega shards game state by player region; Adobe shards assets by tenant — all using these same primitives.

Best practices

• Model query patterns first; pick the shard key from the queries, not the entities.
• Run the chunk balancer in off-hours windows for very large collections.
• Monitor db.printShardingStatus() & balancer rounds; alert on imbalance.
• Continuously archive cold data; the hot working set should fit cleanly in RAM.

Common mistakes

• Sharding too early — operational complexity beats a well-tuned replica set every time at sub-TB scale.
• Monotonic shard keys — every write goes to the same shard; throughput stalls.
• Forgetting that secondary-key queries become scatter-gather across all shards.