Scaling Plan: Replica Set to Sharded Cluster
Learners will draft a capacity plan and choose a shard key that supports the application's read and write distribution without creating hot spots.
When Do You Need to Scale?
Most applications start with a single MongoDB replica set and never need to shard. Sharding adds significant complexity and should be the last resort, not the first choice. Consider sharding when: your data volume exceeds what a single replica set can store affordably; write throughput exceeds what a single primary can handle; or specific collections are too large to index efficiently in memory. Before sharding, always try vertical scaling (larger instances) and read scaling (distribute reads to secondaries).
Phase 1: Single Replica Set
The standard starting point for any MongoDB deployment is a 3-member replica set: one primary, two secondaries. This provides high availability (automatic failover if the primary fails), data durability (writes replicated to multiple members), and read scaling (send reads to secondaries for reporting workloads). For our e-commerce capstone, a 3-member M30 Atlas cluster handles millions of daily orders comfortably. Start here and measure before considering sharding.
// Capacity metrics to monitor on a single replica set
// (via Atlas Metrics or db.serverStatus())
const metricsToWatch = [
'connections.current', // approaching maxIncomingConnections?
'opcounters.insert', // write ops/sec approaching primary limit?
'mem.resident', // working set fitting in RAM?
'wiredTiger.cache.bytesCurrentlyInCache', // cache utilisation
'replicationLag' // secondaries keeping up?
]All lessons in this course
- Requirements Analysis and Schema Design
- Index Strategy and Query Planner Validation
- Scaling Plan: Replica Set to Sharded Cluster
- Security Hardening and Production Checklist