MongoDB — Part 2: Internals & The Write Path

maang.io System Design Series

What is this?

Back to the records office. Part 1 stayed at the counter — folders, drawers, what goes in a folder. Now we go into the back room where the folders physically live, and watch exactly what a clerk does when someone hands over a change.

A careless clerk would walk straight to the shelf, pull the folder, edit it in place, and reshelve it — slow, and if the building loses power mid-edit you have a half-written folder and no idea what was in flight. MongoDB's clerk is disciplined. First it scribbles the change into an intake logbook by the door (so nothing acknowledged is ever lost, even to a power cut). Then it applies the change to a working copy kept on a nearby desk (fast RAM, no shelf trip). Only periodically does it walk the whole desk's worth of changes back to the permanent shelves in one organized trip.

That back room is the WiredTiger storage engine — MongoDB's default engine since version 3.2 — and understanding it explains every durability and performance promise from Part 1.

The one-line idea: WiredTiger keeps your working set in an in-memory cache, makes writes durable immediately via a journal (a write-ahead log), and only flushes a consistent snapshot to the data files at a checkpoint every ~60 seconds. RAM speed for the hot path, the journal for durability, checkpoints for a clean on-disk baseline — that's the whole trick.

Let's follow a write down into it.