What does a MongoDB write concern of w: "majority" actually guarantee about a write?
answer
- counts members, not milliseconds
- arbiters vote but store nothing
- the guarantee is about surviving an election
- two of three, three of five
basics
~20 sA w: "majority" acknowledgment means the write reached a majority of the replica set's voting, data-bearing members, so it survives an election and cannot be rolled back. It does not mean every member has it.
solid answer
~50 sWrite concern is the per-operation contract for how much replication must be confirmed before the server reports success. `w: "majority"` makes the primary wait until a majority of the **voting, data-bearing** members have applied the write — two of three, three of five. That is exactly the threshold that makes the write **durable across a failover**: any newly elected primary must contain every majority-committed write, so a majority-acknowledged write is never rolled back. `w: 1` only proves the current primary took it; if that primary dies before replicating, the write is discarded during rollback. Arbiters vote but store nothing, so they can never count toward `w`. The cost is latency: the call is as slow as the slowest member of the majority, which matters when the second data-bearing member sits in another region. Write concern says nothing about who can read the write — that is read concern's job.
code
javascript · 4 linesdb.orders.insertOne(
{ _id: 42, total: 199 },
{ writeConcern: { w: "majority", wtimeout: 5000 } }
)go deeper
Be able to say that write concern controls how many replica set members must confirm a write, and that w: "majority" is the safe default while w: 1 and w: 0 trade safety for speed.
Explain the mechanics: which members count toward a majority, why arbiters cannot, how acknowledgment flows back through the oplog, and what j adds on top of w.
Show production judgment — link majority acknowledgment to rollback of un-replicated writes, reason about the latency a cross-region member adds to every majority write, and know why P-S-A topologies stall majority writes.
Own the policy: which workload classes may run below majority, how the cluster-wide default is set and audited, and whether latency problems should be solved by weakening durability or by changing member placement.
## What a write concern is A write concern is a per-operation contract between the client and the server about **how much replication and durability must be confirmed before the server reports success**. It is a document with up to three fields: - `w` — how many members must acknowledge (a number, or the string `"majority"`, or a custom name defined in the replica set configuration). - `j` — whether that acknowledgment requires the change to be committed to the on-disk journal. - `wtimeout` — how long the primary waits for the `w` part before returning a write concern error. Write concern controls **durability and acknowledgment only**. It says nothing about which reads can see the write, and it does not make a multi-document operation atomic. ## What "majority" counts `w: "majority"` means a majority of the **voting, data-bearing** members of the replica set. In the standard three-member set (one primary, two secondaries) that is two members: the primary plus any one secondary. In a five-member set it is three. Arbiters vote in elections but hold no data, so an arbiter can never satisfy part of `w`. In a primary–secondary–arbiter set, `w: "majority"` still requires **both** data-bearing members, which is why losing one secondary in a P-S-A topology stalls majority writes even though the set still has a primary. Acknowledgment is counted through replication, not through extra client round-trips: secondaries pull the oplog entry, apply it, and report their applied position back to the primary, which then answers the waiting client. ## Why the majority threshold is the interesting one A member can only win an election if it is up to date with a majority of the set. Therefore any write that has reached a majority is present on every possible future primary, and a write that has **not** reached a majority may be on a member that later has to discard it. When a stale ex-primary rejoins, MongoDB rolls back the writes it accepted that never became majority-committed, writing them out as rollback files rather than replaying them. So the practical statement is: `w: 1` means *"one server has it right now"*; `w: "majority"` means *"this write is part of the cluster's permanent history"*. Money movement, account creation and anything you would be embarrassed to lose belongs at `w: "majority"`. ## Journaling and `j` `w` counts members; `j` is about durability on a single member's disk. `j: true` requires the write to be in the on-disk journal, not merely in memory, so it survives an unexpected process or machine restart of that member. In a replica set, the two dials are complementary: `w: "majority"` protects against losing the node, `j: true` protects against losing the process. Replica sets have a configuration setting, `writeConcernMajorityJournalDefault`, that is enabled by default, so `w: "majority"` already implies journaled acknowledgment on the acknowledging members. You normally do not need to write `j: true` alongside `w: "majority"` unless someone has turned that setting off. ## The cost A majority write is as slow as the **slowest member of the fastest majority**. On a single-region three-member set that is a few milliseconds. Stretch the set across regions and the second data-bearing member may be 80 ms away, so every majority write inherits that round trip. The usual fixes are topology fixes — place enough data-bearing members close to the primary, keep distant members as extra copies beyond the majority — rather than silently downgrading `w`. ## `w: 1` and `w: 0` `w: 1` waits only for the primary. `w: 0` is fire-and-forget: the server sends no acknowledgment at all, so the client cannot distinguish success from a duplicate-key error or a full disk. `w: 0` is defensible only for genuinely disposable data, and even then it hides real errors. ## Where it is set Write concern can come from the connection string (`w=majority`), the client, database or collection handle, or the individual operation, with the most specific winning. Since MongoDB 5.0 the **implicit default** write concern is `majority`, except in sets with arbiters where the data-bearing voting members do not themselves form a majority of the voting members — there the implicit default drops to `w: 1`. Administrators can also set a cluster-wide default explicitly with the `setDefaultRWConcern` command. ## Common misreadings It is not "all members", it is not "the write is visible to every reader", and it is not a transaction. A majority-acknowledged write is durable; whether a given reader sees it depends on where that reader is pointed and with what read concern.
- What does adding j: true to a write concern give you that w: "majority" alone does not?`w` counts how many members took the write; `j` requires it to be in that member's on-disk journal rather than only in memory, so it survives a process or host crash on that member. Replica sets enable `writeConcernMajorityJournalDefault`, so a majority write is already journaled on the acknowledging members unless that setting was disabled.
- In a primary-secondary-arbiter replica set, what happens to majority writes when the secondary goes down?They stall. The arbiter votes so the primary stays elected, but it stores no data, so the only way to reach a data-bearing majority is the primary plus that one secondary. Majority writes then block until `wtimeout` or until the secondary returns. This is a standard argument against P-S-A topologies for durability-sensitive workloads.
- Does w: "majority" mean other clients can immediately read the write from any member?No. Write concern governs acknowledgment and durability, not visibility. A secondary may not have applied the write yet, and a read with `readConcern: "majority"` on a lagging member returns that member's view of the majority-committed data. Read visibility is controlled by read preference and read concern, which are separate dials.
Think of it as getting a document countersigned by enough board members that no future board can deny it was approved — one signature is not enough if that signer resigns.
saying these in an interview costs you the question
- Says w: majority means all replica set members have the write
- Thinks arbiters count toward satisfying the w value
- Believes w: 1 writes can never be lost once acknowledged
- Confuses write concern with read visibility or with transactions
- Claims j: true is redundant because writes always hit disk immediately