In Module 3, we briefly touched on MongoDB’s architecture. We learned that you should never run a production database on a single server because it creates a Single Point of Failure (SPOF). If that server loses power, your entire business goes offline.

To solve this, MongoDB uses Replication.

Replication is the process of synchronizing data across multiple servers. In MongoDB, this group of synchronized servers is called a Replica Set.

In this module, we will dive deep into how a Replica Set actually works under the hood.

What is a Replica Set?

A Replica Set is a cluster of mongod instances (MongoDB servers) that maintain the exact same data set.

A standard Replica Set requires a minimum of three nodes (servers). Why three? Because in the event of a failure, the surviving servers need a “majority vote” to make decisions. If you only had two servers and one died, the surviving server wouldn’t have a majority (1 out of 2 is only 50%), and the system would halt to protect the data.

Note: MongoDB Atlas provisions a 3-node Replica Set for you by default, even on the free tier!

The Primary Node

In every Replica Set, there is exactly one Primary Node at any given time.

The Primary Node is the boss of the cluster. It is the only server authorized to accept Write Operations (insertOne, updateOne, deleteMany, etc.).

When your application sends a Write command, the Primary Node does two things:

It applies the change to its own dataset.
It records the exact operation into a special capped collection called the oplog (Operations Log).

All changes to the cluster’s data must flow through the Primary Node.

The Secondary Nodes

The remaining servers in the Replica Set are Secondary Nodes. Their primary job is to maintain a perfect, real-time mirror image of the Primary Node’s data.

How do they do this? Asynchronous Replication. The Secondary Nodes continuously “tail” (monitor) the Primary Node’s oplog. Whenever the Primary logs a new operation (e.g., “inserted user John Doe”), the Secondaries immediately copy that operation and apply it to their own datasets.

Read Preferences

While Secondaries cannot accept Write operations, they can accept Read operations (find, aggregate). This allows you to scale your database’s read capacity!

In your application code, you can configure your Read Preference:

primary (Default): All reads go to the Primary. (Ensures you get the most up-to-date data).
secondary: All reads go to the Secondaries. (Great for heavy analytics queries so you don’t slow down the Primary).
nearest: Reads go to whichever server has the lowest network latency.

Failover and High Availability

The entire purpose of a Replica Set is High Availability (staying online even when hardware breaks).

The nodes in a Replica Set constantly communicate with each other by sending “Heartbeat” pings every 2 seconds. These pings say, “I am alive and functioning normally.”

If the Primary Node is unplugged, catches fire, or experiences a network partition, the Secondary Nodes will notice that the Primary’s heartbeats have stopped. If 10 seconds pass without a heartbeat, the Secondaries officially declare the Primary “Dead.”

This triggers the Automated Failover process.

The Election Process

Once the Primary is declared dead, the database cannot accept any new Write operations. It must urgently promote a new Primary. It does this through an Election.

A Secondary Node (usually the one with the most up-to-date oplog) nominates itself to be the new Primary.
It requests votes from all other surviving nodes.
The other nodes check to ensure the nominee’s data is actually up-to-date.
If a strict majority of the original nodes vote “Yes,” the nominee is instantly promoted to Primary.

This entire election process typically takes less than 12 seconds. During those 12 seconds, your application cannot write data, but it can continue reading data from the Secondaries.

Once the election finishes, the new Primary begins accepting writes, and your application is back to normal—without human intervention!

What happens when the dead server comes back?

If the server that caught fire is repaired and turned back on, it will reconnect to the cluster. It will immediately realize that an Election took place and someone else is the boss now.

It will automatically demote itself to a Secondary Node, download the oplog to catch up on any data it missed while it was offline, and rejoin the team!

Summary

Replication guarantees that your data is safe and your application stays online.

Replica Sets require a minimum of 3 nodes to function properly.
The Primary Node handles all writes and generates the oplog.
Secondary Nodes replicate the oplog and can handle read-heavy traffic.
If the Primary dies, the surviving nodes hold an Election to promote a new Primary in seconds.

Replication solves the problem of “Hardware Failure”. But what if you have so much data that it physically cannot fit on the hard drive of a single server?

In Module 19, we will explore how MongoDB solves the problem of massive scale using Sharding!