Understand replication and scaling

MongoDB has two scaling mechanisms that beginners constantly mix up. A replica set copies the same data to several servers for availability. Sharding splits a collection across several servers for capacity. They solve different problems, and adding the wrong one is expensive.

Replica sets: surviving a dead server

A replica set is typically three nodes. One is the primary and takes all writes; the others replicate its operation log. When the primary dies, the remaining members hold an election and promote a new primary, usually within seconds. Every Atlas deployment is a replica set — this is the baseline for anything in production.

Replication is asynchronous, which forces two explicit choices. Write concern decides when a write counts as done:

db.orders.insertOne(
  { item: 'book', qty: 1 },
  { writeConcern: { w: 'majority' } }
)

w: 'majority' waits until most members have the write. w: 1 returns after the primary alone — faster, but if that primary dies before replicating, the acknowledged write is rolled back. For data you cannot lose, use majority.

Read preference decides where reads go. Reading from secondaries spreads load but can return slightly stale data. The classic bug: a user saves a change, the next page reads from a lagging secondary, and their edit “disappears” for a few seconds. If that is unacceptable, read from the primary or use appropriate read concern.

Sharding: outgrowing one machine

Sharding distributes a collection across shards, routed by a shard key. The key must spread writes evenly and appear in your common queries, so the router can target one shard instead of broadcasting to all of them. A monotonically increasing key (like a timestamp) funnels every insert to one shard; a key missing from queries makes every read a scatter-gather. Shard keys are hard to change later, so this decision deserves real care.

Do not add sharding to fix one slow unindexed query. Sharding adds routers, config servers, and operational weight — an index costs none of that.

Close with the drill from the exercise: draw the failure of a replica-set primary (evidence: brief write errors, election in the logs; recovery: automatic failover) and of one overloaded shard (evidence: latency on a subset of keys, uneven shard sizes; recovery: rebalancing or a better shard key). If you cannot name the evidence, you are not ready to operate the topology.