Scaling MongoDB to 100K+ Writes per Second

Scaling MongoDB to 100,000 writes per second is not a tuning exercise. It is an architectural decision, and like most architectural decisions it comes down to arithmetic once the assumptions are honest. So let me start with honest assumptions: a realistic MongoDB Atlas shard with 32 GB of RAM, 8 vCPUs and standard SSD storage, with no provisioned IOPS. Nothing exotic, an attainable production configuration. Under controlled conditions (moderate document size, few secondary indexes, bulk writes, no inline aggregation, a write concern aligned to the SLA) a shard of that tier sustains roughly 18,000 inserts per second. That number is the building block for everything that follows.

What 100K writes per second means

One hundred thousand writes a second is six million a minute, 360 million an hour, 8.64 billion a day. At that rate the behaviour of a single node changes character. Vertical scaling plateaus, because however much RAM, CPU and I/O you buy, every operation still funnels through one storage engine, one disk subsystem and one replication stream. I/O stops being invisible, replication pressure grows, and the first hot spot destroys whatever symmetry you had. The only stable strategy is horizontal: distribute the writes across independent write engines, each with its own CPU, memory, disk bandwidth and replication capacity, so that the cluster ingests in parallel instead of through a bottleneck.

One shard, eighteen thousand inserts

If one shard of our tier handles about 18K inserts per second, four shards give roughly 72K, five give 90K, six give 108K. Six shards of ordinary hardware cross the 100K threshold, with no pre-allocated IOPS and no vertical extremes. The reason the sum holds is that each shard has its own storage engine, writes to its own disk, replicates independently and burns its own CPU and memory. When writes are evenly distributed there is no shared write bottleneck, and total cluster throughput becomes, to a first approximation, the sum of the shard throughputs.

The model survives contact with real hardware. The Atlas metrics snapshot below shows sustained ingestion of about 80K inserts per second across five shards, around 16K per shard, in line with the expected per-shard capacity.

The gap between the theoretical ceiling of 90K (five times 18K) and the observed 80K is real-world overhead: replication, network variability, write concern constraints. It is also the confirmation that throughput grows in proportion to shard count for as long as distribution symmetry is preserved. Everything else in this piece is about preserving that symmetry.

The shard key is existential

At 100K per second the quality of the shard key stops being a design preference and becomes the ceiling of the whole cluster. The key must have high cardinality, distribute uniformly, avoid monotonic growth and route deterministically:

sh.shardCollection("db.collection", { partitionKey: 1 })

Do the arithmetic on a small imbalance. At 18K per shard, a 10 percent skew puts 19.8K on one shard and 16.2K on another, and the overloaded shard becomes the cluster’s ceiling while the others idle. Distribution has to be symmetric, and at this scale shard key design cannot be separated from data modelling: document structure, cardinality and write patterns feed directly into distribution symmetry and write amplification, a theme I explored in the talk on data modelling for scalable MongoDB architectures.

Pre-split, then place the chunks yourself

On standard disks with no provisioned IOPS you cannot afford chunk migrations during peak ingestion: a migration consumes disk bandwidth, replication bandwidth, CPU and network, exactly the resources you want dedicated to writes. So split the collection before the load arrives and move the chunks explicitly, while the cluster is quiet.

sh.splitAt("db.collection", { partitionKey: 250000 })
sh.splitAt("db.collection", { partitionKey: 500000 })
sh.splitAt("db.collection", { partitionKey: 750000 })

Predictability is stability. The balancer should never be competing with ingestion for the same disk.

A clean write path

Inefficiencies that are invisible at a thousand writes a second multiply instantly at a hundred thousand. The write path should be as lean as the workload allows: bulk writes with insertMany and ordered set to false, lean documents, minimal secondary indexes, no multi-document transactions on the hot path, and a write concern chosen against actual durability requirements rather than habit:

writeConcern: { w: "majority", j: false }

Indexes deserve their own sentence, because every secondary index adds write amplification. A shard that sustains 18K per second with two indexes might drop to 10K with seven. Index discipline, more than any server parameter, defines the throughput ceiling.

Storage is the other quiet constraint. Standard Atlas storage without provisioned IOPS gives you burst capacity, but sustained I/O has to stay below the disk’s limits and write spikes show up as latency variation. At 18K per shard, disk latency must stay flat, the journaling strategy matters and replication lag has to be watched. This is also why horizontal scaling is safer than vertical: a bigger node concentrates pressure on one disk subsystem, more shards spread it across many.

Finally, keep ingestion separate from everything else. At this rate the write path should never share capacity with heavy aggregations, complex validations, cross-document checks or analytical queries. Ingest, emit completion events, consume them through change streams, and run analytics asynchronously. Isolation protects throughput.

What breaks it

Against the 18K per shard baseline, the failure modes I see most often are the same handful:

• monotonic shard keys
• too many secondary indexes
• large documents
• chunk migrations during peak
• journaling under disk saturation
• insufficient connection pooling
• application-side bottlenecks that no database can fix

Each of them is small on its own. At 100K per second small inefficiencies scale catastrophically.

What sustains six shards above 100K is symmetry: identical hardware on every shard, CPU below saturation, disk below the I/O ceiling, stable replication lag, a balancer that never competes with ingestion. Cluster averages are misleading here; per-shard metrics tell the truth. Get the shard key right, keep the distribution deterministic, keep the write path clean and the indexes disciplined, and 100K writes per second stops being a miracle. It becomes arithmetic, and when performance becomes arithmetic, your architecture is correct.