Description

Journaling docs at https://docs.mongodb.com/manual/core/journaling/ says "MongoDB syncs the buffered journal data to disk every 50 milliseconds (Starting in MongoDB 3.2)"

However this is incorrect (or at least not completely the answer) and is potentially causing users to think MongoDB can't provide a highly available data solution (ie. write concern majority) and also yield response times in far less than 50 milliseconds at the same time. 

However, for example: I am seeing in my own tests, with write concern = majority for an Atlas hosted replica-set across 3 availability zones in one region, an average response time of around 5ms and maximum response time of around 10ms.

I've just been informed that actually for write concern majority at least, the journal behaviour is: 

• write is journaled and flushed to disk immediately on the primary - no waiting for next journal batch write - mongod does this on a separate thread so that multiple writes can be part of the same flush its not one flush per write
• once journaled to disk on primary disk then the change is available to be replicated
• each secondary listening to the primary's oplog does the same and flushes journal to disk as soon as it received the change before then acknowledging back

Therefore the latency of a client performing a write to a 3 node replica set using a write concern of majority is: 2Xjournal-flush + 1X network roundtrip, which will be in the order of 5-10 milliseconds for SSD disks and a fairly local network of 3 replicas. 

Scope of changes

Impact to Other Docs

MVP (Work and Date)

Resources (Scope or Design Docs, Invision, etc.)