MongoDB — Part 3: Internals Advanced — Replication, Sharding & Consistency

maang.io System Design Series

What is this?

One records office is a single point of failure — burn the building down and the folders are gone; get too many patients and one clerk can't keep up. Real institutions solve both problems structurally. They keep branch offices with photocopies of every folder, kept in sync from a head office. And when one building can't physically hold all the folders, they split the archive across several buildings by some rule (say, surname), with a receptionist who knows which building holds which folders.

Those are MongoDB's two scaling axes, and they're independent:

• Replication (replica sets) → availability & durability. Copies of the same data on multiple nodes; survive node loss.
• Sharding → horizontal scale. Different slices of the data on different nodes; grow past one machine.

The one-line idea: a replica set keeps N copies of the data with one primary taking writes and secondaries tailing an oplog to stay in sync; sharding spreads the collection across many replica sets by a shard key, with a router (mongos) and a metadata directory (config servers) sending each query to the right shard. Consistency is a dial you set per operation with write/read concerns and read preferences.

This is the chapter where MongoDB becomes a distributed system. Let's build it up.