MongoDB Replica Sets

A replica set is a group of MongoDB servers that maintain the same data set, providing redundancy and high availability.

Purpose

• Data redundancy and disaster recovery
• Automated failover
• Increased read capacity

Components

A replica set consists of multiple nodes: one primary node and one or more secondary nodes. At least three nodes are recommended.

How It Works

• All write operations go to the primary node, which records them in an operation log (oplog).
• Secondary nodes asynchronously replicate the primary's oplog and apply those operations to maintain data consistency.
• Each node sends heartbeat signals to others to monitor health. If the primary fails, an election among secondaries promotes a new primary automatically.
• Read requests can be served by both primary and secondary nodes.

MongoDB Sharding

Sharding distributes data across multiple servers (shards), each handling a subset of the data and capable of independent read/write operations.

Purpose

• Horizontal scaling for large datasets
• Improved write and read throughput

Components

• Router (mongos): Accepts client requests, looks up metadata from the config server, and routes requests to the appropriate shard. Can be horizontally scaled.
• Config Server: Stores cluster metadata such as shard locations and chunk distribution. Must be deployed as a replica set for reliability.
• Shard Server: Stores a portion of the cluster's data and processes operations forwarded by the router. Shards can be scaled horizontally.

Sharding Strategies

• Range-based sharding: Simple to implement but prone to hot spots if the shard key distribution is uneven.
• Hash-based sharding: Distributes data more evenly across shards; however, range queries become inefficient.
• Tag-aware sharding: Aligns data distribution with bussiness logic (e.g., geo-location). May result in uneven distribution but often matches application requirements better.

Sharded Replica Sets

Combining sharding with replica sets enhances both scalability and availability. Each shard is itself a replicca set, providing data redundancy within each shard.

Components

• Router (mongos)
• Config Server (as a replica set)
• Each shard is a replica set (primary + one or more secondaries)

How It Works

• The overall architecture follows the sharding model: data is partitioned across shards.
• Within each shard, the replica set mechanism ensures high availability and automatic failover if the shard's primary fails.
• The two layers operate independently but together.

Typical Evolution Path

1. Standalone instance – For development or low-traffic production.
2. Replica set – Introduces redundancy and automatic failover.
3. Sharded replica sets – Adds horizontal scaling while preserving high availability.

Jumping directly to a sharded cluster without first using replica sets is not recommended due to increased architectural complexity, higher latency, and more challenging maintenance.