How does MongoDB handle Write Concern (w: 1 vs w: majority) and what are the latency trade-offs?

With w: 1, a write operation is considered successful as soon as the primary node of the replica set has applied the write to its memory . It does not wait for the write to be replicated to any secondary nodes or to be written to the on-disk journal . This offers the lowest latency because the client receives acknowledgment after a single network round-trip to the primary and minimal processing. However, it presents a durability risk: if the primary fails immediately after acknowledging the write but before the data can be replicated to a secondary, that write can be rolled back and lost when a new primary is elected .

A write with w: "majority" is only acknowledged after it has been applied by a majority of the data-bearing voting members in the replica set . For a 3-member replica set (P-S-S), this means the primary and at least one secondary must acknowledge the write . This process involves the primary waiting for confirmation that the secondary has received and applied the operation, typically by reading from its oplog . The latency trade-off is significant because the write now involves network round-trips to secondaries and additional disk I/O on those nodes. Quantifiably, enabling w: "majority" in a 3-node cluster can reduce write throughput by approximately 40-60% compared to w:1 . However, it provides a much stronger durability guarantee. Data acknowledged with w: "majority" is far less likely to be rolled back after a failover, as a majority of nodes already have a copy .

The latency difference stems from the number of network hops and disk operations required. A w:1 operation completes with just a write to the primary's memory. A w:"majority" operation adds the time for the primary to wait for one or more secondaries to fetch, apply, and acknowledge the change, which is fundamentally limited by the inter-node network latency within your replica set . This is why the performance penalty is higher in geographically distributed clusters.

Write Concern can be further refined with two important options. The j: true option requests acknowledgment that the write has been written to the on-disk journal on each node specified by the w setting . Combining w: "majority" with j: true offers the highest level of data safety, guarding against both node failure and OS crashes, but it adds significant latency due to disk flush operations . The wtimeout parameter (in milliseconds) is also critical for w: "majority". It prevents write operations from blocking indefinitely if the required number of acknowledgments cannot be met, for instance, due to a network partition or a failed secondary . If the wtimeout is exceeded, the operation returns an error, though the write may still succeed on a subset of nodes.