Read Preferences, Write Concerns, and MongoDB at Scale

MongoDB performance at scale requires understanding the WiredTiger storage engine’s behaviour, designing for horizontal scaling with sharding, and using Atlas’s operational tooling to find and fix problems before they become outages. Read preferences control which replica set members handle reads — enabling geographic locality, read scaling, and reporting workloads without impacting the primary. Write concerns control durability guarantees. Sharding distributes data across multiple servers when a single node’s capacity is insufficient. This lesson covers these advanced operational patterns that production MongoDB deployments rely on.

Read Preference Modes #

Write Concern Options #

Complete Advanced MongoDB Operations #

const mongoose = require('mongoose');
const Task     = require('../models/task.model');

// ── Per-operation read preference ─────────────────────────────────────────

// Primary for consistency-critical reads (after a write)
async function getTaskAfterUpdate(id) {
    return Task.findById(id)
               .read('primary')     // ensure we see the write
               .lean();
}

// Secondary for analytics and reporting — offloads the primary
async function generateTaskReport(userId) {
    return Task.aggregate([
        { $match: { user: new mongoose.Types.ObjectId(userId) } },
        { $group: {
            _id:      '$status',
            count:    { $sum: 1 },
            avgAge:   { $avg: { $subtract: [new Date(), '$createdAt'] } },
        }},
    ]).read('secondary');
}

// Nearest for multi-region: read from closest data centre
async function getUserTasks(userId) {
    return Task.find({ user: userId }).read('nearest').lean();
}

// ── Write concern per operation ───────────────────────────────────────────

// Low-durability for non-critical writes (user activity tracking)
async function recordTaskView(taskId, userId) {
    return Task.updateOne(
        { _id: taskId },
        { $inc: { viewCount: 1 }, $set: { lastViewedBy: userId } },
        { writeConcern: { w: 1 } }   // just primary ack — a missed view doesn't matter
    );
}

// High-durability for critical writes (payment, deletion)
async function permanentlyDeleteTask(taskId) {
    return Task.deleteOne(
        { _id: taskId },
        { writeConcern: { w: 'majority', j: true } }  // replicated + journaled
    );
}

// ── Collation — language-aware string sorting ─────────────────────────────
// Sort tasks alphabetically in French locale (handles accents correctly)
async function getTasksSorted(userId) {
    return Task.find({ user: userId })
               .collation({ locale: 'fr', strength: 1 })  // case-insensitive French sort
               .sort({ title: 1 })
               .lean();
}

// ── Partial index for soft-delete pattern ────────────────────────────────
// In schema definition:
// taskSchema.index(
//     { user: 1, createdAt: -1 },
//     { partialFilterExpression: { deletedAt: { $exists: false } } }
// );
// This index only contains non-deleted tasks — smaller, faster for common queries

// ── Atlas Performance Advisor — interpreting suggestions ─────────────────
// Atlas surfaces these via its UI; here's how to check manually:
async function checkSlowQueries() {
    const admin = mongoose.connection.db.admin();
    const profile = await mongoose.connection.db
        .collection('system.profile')
        .find({ millis: { $gt: 100 } })
        .sort({ ts: -1 })
        .limit(10)
        .toArray();

    return profile.map(op => ({
        operation:   op.op,
        collection:  op.ns,
        durationMs:  op.millis,
        docsExamined:op.docsExamined,
        docsReturned:op.nreturned,
        keysExamined:op.keysExamined,
        planSummary: op.planSummary,
    }));
}

// Enable profiling for slow queries (100ms threshold)
async function enableSlowQueryProfiling() {
    await mongoose.connection.db.command({
        profile: 1,
        slowms:  100,
        sampleRate: 0.5,   // profile 50% of slow queries to reduce overhead
    });
}

// ── Connection monitoring ─────────────────────────────────────────────────
mongoose.connection.on('commandStarted', event => {
    if (['find', 'aggregate', 'update', 'insert', 'delete'].includes(event.commandName)) {
        // Log command for query audit
    }
});

mongoose.connection.on('commandSucceeded', event => {
    if (event.duration > 100) {
        logger.warn('Slow MongoDB command', {
            command:    event.commandName,
            durationMs: event.duration,
        });
    }
});

How It Works #

Step 1 — Secondary Reads Offload the Primary #

In a 3-node replica set (1 primary, 2 secondaries), directing analytics queries to secondary read preference means the primary only handles writes and latency-sensitive reads. A reporting query that takes 5 seconds and accesses 100,000 documents runs on a secondary without impacting the primary’s CPU, memory, or I/O — it does not slow down the 50ms API response times on the primary. This is the most straightforward form of read scaling before considering sharding.

Step 2 — Write Concern Majority Survives Primary Failures #

w: 'majority' means the write is acknowledged only after it has been replicated to a majority of replica set members. In a 3-node set, that means 2 nodes. If the primary crashes immediately after the write, one of the secondaries has the data and will become the new primary without data loss. With w: 1 (primary ack only), a crash before replication means the write is lost — even though the application received a success acknowledgement.

Step 3 — Collation Enables Correct Language-Aware Sorting #

String sorting in MongoDB uses raw byte comparison by default — “Ångström” sorts after “Zebra” because ‘Å’ has a higher code point than ‘Z’. Collation specifies a locale that defines language-specific rules: case folding, accent normalisation, and character equivalences. { locale: 'fr', strength: 1 } sorts case-insensitively with accents treated as equivalent to their base characters — “café” and “Cafe” sort together as expected in a French language UI.

Step 4 — Partial Indexes Reduce Index Size and Maintenance Cost #

A partial index on { user: 1, createdAt: -1 } with partialFilterExpression: { deletedAt: { $exists: false } } only indexes non-deleted documents. For a soft-delete pattern where 30% of documents are deleted, the index is 30% smaller and 30% cheaper to maintain on writes. Queries that always include { deletedAt: { $exists: false } } in their filter will use this index — saving I/O for both reads and write operations.

Step 5 — MongoDB Monitoring Events Track Command Performance #

Mongoose exposes MongoDB’s Command Monitoring protocol via connection events: commandStarted, commandSucceeded, commandFailed. The commandSucceeded event includes the command duration in milliseconds. Logging slow commands (over 100ms) in production — without enabling the full slow query profiler — provides targeted visibility into database performance with minimal overhead. Atlas’s Performance Advisor also analyses these patterns automatically and suggests indexes.

Quick Reference #