Deep dive into Write Concern. What happens under the hood when you use { w: 'majority', j: true }?

The j: true option requests acknowledgment that the write operation has been written to the on-disk journal . When combined with w: "majority", this request applies to every member that contributes to the majority . Without j: true, a node might acknowledge the write as soon as it's in memory, leaving a window where a crash could result in data loss. With j: true, the acknowledgment is only sent after the journal flush, guaranteeing durability against a hard shutdown.

The replica set configuration setting writeConcernMajorityJournalDefault plays a critical role in how { w: "majority", j: true } behaves .

Therefore, when you explicitly set { w: "majority", j: true }, you are overriding any default behavior and demanding durable acknowledgment from the majority, regardless of how writeConcernMajorityJournalDefault is configured.

This strong consistency guarantee comes with a significant performance cost . j: true forces a disk flush operation, which is inherently slow. Additionally, w: "majority" requires waiting for network round-trips to other nodes. The latency of a write with this setting will be at least as high as the slowest of these operations across the majority of nodes. Consequently, this write concern is typically reserved for critical data where data loss is unacceptable.

It is best practice to combine this write concern with the wtimeout option . For example: { w: "majority", j: true, wtimeout: 5000 }. This prevents the client from blocking indefinitely if the required majority of nodes cannot be reached or are too slow to flush their journals. If the timeout is exceeded, the operation fails with a write concern error, but the write may still succeed on a subset of nodes .