Why Go All‑in on MongoDB? Architecture, HA, Sharding & Schema Design Explained

Background and Database Requirements

A fast‑growing social e‑commerce platform with millions of users and annual sales approaching fifty billion needs a database that is safe, stable, highly available, and high‑performance. The data model must accommodate rapid growth of orders, SKUs, and member information over months and years.

Why MongoDB

MongoDB was chosen because it delivers the required performance, provides built‑in high availability via replica sets, and offers a flexible document model that reduces schema rigidity and development overhead.

MongoDB High‑Availability Architecture

MongoDB achieves 99.99 % availability using a replica‑set configuration. One primary node handles all reads and writes, while two secondary nodes replicate the data. If the primary fails, the secondaries hold an election to promote a new primary, ensuring continuous service. The election algorithm is a Raft‑style consensus variant that pulls data from the primary to the secondaries, reducing load on the primary.

Replica‑Set Size Limits and Non‑Voting Members

MongoDB allows up to 50 members in a replica set, but only seven may have voting rights. Additional members can be configured as non‑voting secondaries (or arbiters) for read‑only workloads, enabling read‑write splitting similar to MySQL.

{
  "_id": 0,
  "host": "hostname:port",
  "arbiterOnly": false,
  "buildIndexes": true,
  "hidden": false,
  "priority": 0, // 0 makes the member non‑voting
  "tags": {},
  "slaveDelay": NumberLong(0),
  "votes": 0 // non‑voting
}

Write Concern and Data Safety

Three write scenarios illustrate data safety:

Primary acknowledges the write, but secondaries have not yet replicated. If the primary crashes, the write is lost.

One secondary has replicated the write. If both primary and that secondary crash, the write is lost.

Two secondaries have replicated the write. The data remains safe after a primary failure.

The recommended compromise is to use a majority write concern, which balances reliability and latency.

db.products.insert(
   { item: "envelopes", qty: 100, type: "Clasp" },
   { writeConcern: { w: "majority", wtimeout: 5000 } }
)

Sharding Overview

Sharding distributes a collection across multiple shards based on a shard key, enabling horizontal scaling. The sharding cluster consists of:

Shard : stores data chunks; each shard is typically a replica set.

Config Server : a replica set that holds metadata and chunk information.

Mongos : a query router that directs client operations to the appropriate shard.

The balancer automatically migrates chunks from oversized shards to smaller ones. Careful shard‑key selection is essential to avoid uneven data distribution and excessive chunk migrations.

Schema Flexibility in MongoDB

MongoDB’s document model permits heterogeneous fields within the same collection and easy schema evolution. For a 1:N relationship such as a user with multiple addresses, a single document can embed an array of address objects, eliminating the need for separate tables and joins.

{
  "_id": "joe",
  "name": "Joe Bookreader",
  "addresses": [
    { "street": "123 Fake Street", "city": "Faketon", "state": "MA", "zip": "12345" },
    { "street": "1 Some Other Street", "city": "Boston", "state": "MA", "zip": "12345" }
  ]
}

This flexibility reduces development overhead and allows developers to write performant queries without deep SQL expertise.

Key Operational Considerations

Replica‑set voting limit : Only seven members can vote to keep elections fast; additional members should be configured as non‑voting secondaries or arbiters.

Shard‑key design : Choose a high‑cardinality, evenly distributed key to minimize chunk migrations and balance load.

Balancer impact : The balancer runs continuously but can affect performance; schedule heavy migrations during off‑peak windows.

Write concern trade‑off : Majority write concern provides durability with acceptable latency for most workloads.