Problem Statement
Explain the difference between horizontal and vertical scaling. Why does MongoDB prefer horizontal scaling?
Explanation
Vertical scaling means adding more resources to a single server, such as upgrading CPU, adding more RAM, or using faster storage. It is the simpler approach because your architecture remains unchanged; you just use more powerful hardware. However, vertical scaling has hard limits. There is a maximum amount of RAM, CPU, and storage you can add to a single machine, and costs increase exponentially at the high end.
Horizontal scaling means adding more servers to distribute the load across multiple machines. Instead of one powerful server, you use many commodity servers working together. MongoDB implements horizontal scaling through sharding, where data is partitioned across multiple shards.
MongoDB prefers horizontal scaling for several reasons. First, it has virtually unlimited capacity. You can add shards indefinitely as your data and workload grow. There is no practical upper limit like there is with vertical scaling. Second, it is more cost-effective. Adding commodity servers is cheaper than buying enterprise-grade high-end hardware.
Third, horizontal scaling provides better fault tolerance. With data distributed across multiple servers, the failure of one shard does not take down the entire system. When combined with replica sets on each shard, you have both high availability and horizontal scalability. Fourth, it enables geographic distribution. You can place shards in different data centers or regions to reduce latency for users in different locations.
However, horizontal scaling adds complexity. You need to manage multiple servers, choose good shard keys, and handle distributed queries. Vertical scaling remains viable for smaller deployments or when your data fits on a powerful single server. Many deployments use both strategies: vertical scaling for individual servers and horizontal scaling across multiple shards.
Code Solution
SolutionRead Only
// Vertical scaling (single server)
// Year 1: 16GB RAM, 4 cores, 500GB storage
// Year 2: 64GB RAM, 16 cores, 2TB storage
// Year 3: 256GB RAM, 32 cores, 8TB storage
// Eventually: Cannot scale further, very expensive
// Horizontal scaling (sharding)
// Year 1: 3 shards, 16GB RAM each
// Year 2: 6 shards, 16GB RAM each
// Year 3: 12 shards, 16GB RAM each
// Can continue adding shards indefinitely
// Sharding setup for horizontal scaling
sh.addShard("shard1/host1:27017")
sh.addShard("shard2/host2:27017")
sh.addShard("shard3/host3:27017")
// Add more shards as needed