The first question before sharding is whether the work can be divided along with the data. A database may be large while most activity concentrates on a small portion. If that portion moves intact to one new server, the other nodes do not solve the bottleneck. The company has bought a distributed system with the same constraint.
Sharding places different parts of a dataset on different nodes. Application or infrastructure routing determines which part should handle a request. It distributes storage and processing when the rule matches how the product uses its data. Choosing that rule can matter more than adding machines.
Replication, partitioning and sharding solve different problems
Replication creates copies. Sharding divides the dataset. Table partitioning, such as separating monthly history inside one database, can improve maintenance without distributing computation across independent servers. These techniques can be combined, but they are not interchangeable.
A shard may itself have a primary and replicas. Multiple shards do not automatically provide availability: redundancy, routing and tested failover still matter. The MongoDB sharding overview describes those components separately.
Identify the actual constraint first: memory, storage, write throughput, expensive queries or contention on the same records. Reads may need a better index or a replica. Historical data may need a retention policy or table partitioning. Adding empty shards does not remove contention on one heavily updated record.
A convenient key may distribute work badly
Consider a service used by several companies. A tenant identifier is attractive: a company's users, cases and documents stay together, and its normal screens contact one shard. Then a large customer arrives and generates more work than the rest combined. Equal tenant counts do not mean equal load.
Hashing a key can spread different values across a range. It does not automatically split a huge customer's work if every record has the same tenant key. A dedicated shard, a smaller unit of distribution or a compound key may be necessary. Each choice changes what requests can remain local.
Time also looks like a natural dividing line. Old records occupy old ranges; new records enter the newest range. But with a monotonically increasing range key, new writes may concentrate in one place. More machines storing history do not relieve current ingestion. The shard-key selection guidance identifies this risk.
Study operations as well as gigabytes. Two equally sized shards may receive very different traffic. Cluster-wide averages can hide an overloaded member. Actual customer profiles, update frequency and demanding operations are more useful than a uniform test dataset.
What about queries that need everything?
A query containing a suitable key can be routed directly. A global search or management report may need to contact several shards and merge the results. That adds communication, coordination and exposure to the slowest participant. Increasing node count does not necessarily accelerate the complete request.
Tenant-local screens may work well while your own sales department needs a global list of overdue contracts. Choose how to provide that view: a cross-shard query, a prepared projection or a separate analytics store. Its freshness requirement affects which options are acceptable.
Updates need even more care. A cross-shard operation may require a distributed transaction where the database supports it. Otherwise it needs an explicit coordination process. An “all or nothing” business requirement must not quietly become “the records will eventually agree”. Check uniqueness and other constraints too: their enforcement scope must match the promise made by the product.
This is a reason to reconsider data boundaries, not to reject distribution altogether. Keeping common critical operations inside one shard reduces coordination. Rare operations still need a design, such as moving a division between customer organisations after a restructuring.
Moving data becomes routine work
Customers grow unevenly after launch. The platform needs to move data and update routing while the application continues accepting changes. Copying tables is not enough. Establish where writes are authoritative during the move, how intervening changes are captured and when the new location takes over.
Database-managed mechanisms can handle much of that work. The team still needs spare capacity, monitoring and verification. Rebalancing competes with the normal workload. Waiting until storage is completely exhausted leaves very little room to perform the move safely.
Revisit backups as well. Having a backup of every shard does not by itself prove that they restore a consistent application state, especially when workflows cross boundaries. Recovery points and checks after restoration need to be explicit.
Preparation should start before an outage, when measured growth indicates an approaching limit and leaves time to migrate. There is no need to demonstrate the problem by stopping the business. But the forecast should be grounded in observed operations and resource use, not a presentation promising billions of records.
Before approval, run three exercises against a representative workload: a large customer sharply increases activity, a global report runs alongside writes, and one customer's data moves to another node. Ask for the resulting correctness, latency and recovery procedure if each exercise is interrupted. Those results turn sharding from an attractive diagram into a plan the company can evaluate.