On MongoDB 8.0+ (verified against 9.0.0-alpha0, master), when featureFlagReduceMajorityWriteLatency is enabled, a dedicated OplogWriter thread writes fetched oplog entries into the local rs.oplog collection before handing them off to the oplog applier. In steady-state replication this writer runs on a single thread (OplogWriter-0). Under high-throughput / large-document workloads this single thread becomes the replication bottleneck: it saturates one CPU core while the rest of the machine (and the applier threads) sit idle, capping secondary write throughput and, in turn, the whole replica set's sustainable write rate.

This proposal adds a new startup-only server parameter, oplogWriterThreadCount, that lets the steady-state OplogWriter write each oplog batch in parallel on a dedicated worker pool, while fully preserving the Reduce-Majority-Write-Latency design (the feature flag stays on) and without contending with the oplog applier's thread pool.

In our benchmarks this raised secondary-bound insert throughput from ~5.2K ops/s to ~8.6K ops/s (+65%), moving the bottleneck off the single oplog writer thread.
Version context. As of 9.0.0-alpha0,

 featureFlagReduceMajorityWriteLatency is still present and is default: true, fcv_gated: false — i.e. the dedicated single-threaded OplogWriter is the default steady-state write path. This proposal targets that default path.

By the way, I’d like to report an issue: when creating a ticket in MongoDB JIRA, I’m unable to select the issue type. This ticket is actually an improvement / performance optimization, but I cannot choose the appropriate issue type.