Rencana Penskalaan: Dari Set Replika ke Klaster Terpecah

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).

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.

Before sharding, scale reads by routing analytics and reporting queries to secondaries using readPreference: 'secondary'. This offloads read pressure from the primary without adding operational complexity. In Atlas, Analytics Nodes are dedicated secondaries (never elected primary) that absorb heavy aggregation workloads without impacting primary performance. This approach works well until write throughput itself becomes the bottleneck.

Shard when you hit a wall that vertical scaling cannot solve: the primary's write throughput is saturated even with the largest available instance; a collection's working set (data + indexes actively in use) does not fit in the cluster's RAM even on the largest tier; or a specific collection is too large to store on one cluster's disk. In practice, most applications hit RAM limits before write throughput limits — monitor the WiredTiger cache utilisation and working set size monthly.

Only shard the collection(s) that are causing the bottleneck. In our e-commerce platform, the orders collection will grow fastest and generate the most write traffic. The products collection may be large but receives mostly reads that can be served from secondaries. Sharding orders while keeping products unsharded (on every shard as a broadcast collection) is a common, practical approach.

The shard key for orders must distribute writes evenly across shards and support the most common query patterns. Using userId as a hashed shard key distributes writes uniformly because user IDs are high-cardinality and random. The downside: queries scoped to a single user scatter across all shards. A ranged shard key on { userId: 1, _id: 1 } keeps one user's orders on the same shard (faster user-specific queries) but risks hot shards if a few users generate most activity.

If the e-commerce platform serves multiple regions with data residency requirements (EU data must stay in Europe), use zone sharding to pin documents to specific shards based on shard key ranges. Create zones for each region, assign shards to zones, and define which shard key ranges map to each zone. Data for EU users stays on EU-region shards, satisfying GDPR without maintaining separate clusters.

In a sharded cluster, mongos instances are the query router layer. Application drivers connect to mongos (not directly to shards). The mongos reads the config server replica set (which holds the cluster's metadata, chunk maps, and zone assignments) to determine which shard(s) hold the data for each query. Always deploy at least two mongos instances for high availability — they are stateless and can be restarted without data loss.

In a sharded cluster, a targeted query includes the shard key in its filter — mongos routes it to exactly one shard. A scatter-gather query lacks the shard key — mongos must broadcast it to all shards and merge the results. Scatter-gather queries are expensive and should be avoided on hot paths. Design your shard key and query patterns so the most frequent queries include the shard key field.

Build a capacity model: estimate daily document growth rate × average document size to project when each shard will fill. In Atlas, use Cluster Autoscaling to automatically add storage or upgrade instance tiers when usage thresholds are crossed. Set Atlas alerts for: disk usage above 80%, CPU utilisation above 70% for more than 1 hour, and replication lag above 10 seconds. Proactive monitoring prevents reactive scrambles at 3 AM.

Atlas manages the entire sharding infrastructure automatically: provisioning mongos routers, config servers, and shard replica sets; balancing chunks; and patching the cluster. For self-hosted deployments, each component must be provisioned, monitored, and maintained manually — a substantial operational burden. For most teams, the operational savings of Atlas sharding justify the premium over self-hosted, unless compliance requirements mandate on-premises deployment.

Test your understanding of MongoDB & NoSQL Databases concepts from this lesson.

In this lesson you learned: scale vertically and leverage secondary reads before sharding — sharding adds significant complexity that most applications never need, shard key selection must balance write distribution (hashed) against query targeting (ranged), and targeted queries that include the shard key go to a single shard while scatter-gather queries hit all shards and are expensive. Next up we complete the capstone with security hardening and the production readiness checklist.