In this chapter
We'll meet MongoDB's real replication mechanics — replica sets, primary/secondary elections, tunable read/write concerns, change streams, and real multi-document transactions.
The Problem in Real Life
GreenMart's catalog is live, growing, and genuinely load-bearing now — sellers depend on it every day. Sarah isn't guessing at redundancy anymore; MongoDB has a real, built-in answer, with its own name: a replica set.
Mike remembers the six-second replica-lag moment from early on — the one where Sarah had to choose between answering fast and answering guaranteed-correct. He asks the obvious follow-up.
So which one do we pick — fast, or correct?
Mike
One Copy vs. A Replica Set
A replica set, not just "more copies"
One primary accepting writes, secondaries replicating from it and standing ready to take over.
Automatic elections
If the primary fails, the replica set elects a new one from the remaining secondaries — no manual failover needed.
writeConcern and readConcern
The Consistency-vs-Availability trade-off, made real and tunable — chosen per operation, not fixed for the whole database.
Real multi-document transactions
"NoSQL means no transactions" isn't true here — MongoDB has supported them across documents and collections since v4.0.
Replication & Replica Sets
A quick, honest note before diving in: this chapter and the next one cover the most advanced ground in this whole Act — real distributed-systems mechanics, not just new syntax to memorize. If it takes longer to click than the last few chapters did, that's expected. It isn't a sign anything earlier was skipped.
"Both, depending on the moment," Sarah tells him — and means it literally. A replica set is a group of MongoDB instances holding the same data: one primary, which accepts every write, and one or more secondaries, which continuously replicate from the primary and can serve reads. If the primary ever becomes unreachable, the replica set runs an automatic election among the remaining secondaries and promotes a new primary — no one has to notice and fail over by hand.
| Node | Role | If the primary fails |
|---|---|---|
| Node A | Primary — accepts every write | An automatic election picks a new primary from the remaining secondaries |
| Node B | Secondary — replicates from the primary, can serve reads | Eligible to become the new primary |
| Node C | Secondary — replicates from the primary, can serve reads | Eligible to become the new primary |
The same shape as the earlier three-machine example — MongoDB's own real names for it: replica set, primary, secondary, election.
This is the earlier Consistency-vs-Availability trade-off, made concrete and tunable. writeConcern: { w: "majority" } means "don't consider this write successful until a majority of the replica set has it" — favoring correctness. A lighter writeConcern returns faster, favoring availability, at the cost of a brief window where a failure could lose that write. readConcern makes the same choice for reads: "majority" guarantees data acknowledged by most of the replica set; "local" returns whatever the node it happened to hit currently has.
db.listings.updateOne({ _id: "lst-fast-charger-20w" },{ $set: { price: 7.99 } },{ writeConcern: { w: "majority" } })
This simulator runs as a single in-memory copy, so it can't actually demonstrate multi-node replica-set behavior — the syntax above is real MongoDB, shown for what it looks like in practice, not something this Playground can run meaningfully.
A replica set already keeps every secondary continuously informed of every insert, update, and delete, in order — that's the internal mechanism replication itself runs on. Change streams expose that exact same stream of changes directly to GreenMart's own applications, instead of MongoDB keeping it to itself. Subscribing to db.listings.watch() means finding out about a change the moment it happens, without repeatedly polling the database to ask "did anything change yet?"
db.listings.watch().on("change", (event) => {console.log(event.operationType, event.documentKey);})
Not runnable in this single-node simulator, for the same reason as writeConcern above — real change streams depend on the same replication machinery.
One more thing worth correcting directly, since it's a common assumption about NoSQL databases in general: MongoDB has supported real, multi-document transactions since version 4.0 — a group of operations across several documents (even across several collections) that either all succeed together or all roll back together, the exact same all-or-nothing guarantee GreenMart's own relational database has always given its payments. "NoSQL means no transactions" simply isn't true for MongoDB specifically, even though the document model's own atomic single-document updates cover most everyday needs without ever reaching for one.
Key Takeaway
MongoDB doesn't force one answer to the Consistency-vs-Availability question. writeConcern and readConcern let GreenMart choose, per operation, which one this particular read or write actually needs.
Why This Matters
Replica sets solve durability and availability. They don't solve the other half of what GreenMart will eventually need — spreading a dataset too large for any one machine across several. That's a genuinely different problem, and it's exactly where the next chapter goes.
GreenMart's catalog now survives losing a machine, with a real, tunable choice about speed versus certainty on every operation. The next problem isn't about losing data anymore. It's about GreenMart's catalog simply outgrowing what any one machine, primary or not, can hold.