In v8.0, we split the oplog applier so that we write oplog entries independently from applying them, and we updated the primary as soon as possible after writing oplog entries. This allowed us to acknowledge w: majority writes without waiting for them to be applied, thereby increasing the performance of those writes.

In that project, we decided to only apply this benefit to w: majority writes. This was because for tagged and numbered write concerns, we were concerned that customers implicitly relied on read-your-writes behavior. Although this was never explicitly supported in the server, some customers may have utilized this to help increase performance without using causal consistency sessions.

However, we should evaluate if this is still the case today, and if we can give customers the performance benefits of using lastWritten instead of lastApplied.

Acceptance Criteria

Evaluate various write concerns and determine if we can use lastWritten instead of lastApplied to respond to those write concerns. Implement the changes for any write concerns that fall under this category