Causal Consistency and Read and Write Concerns

With MongoDB’s causally consistent client sessions, different combinations of read and write concerns provide different causal consistency guarantees. When causal consistency is defined to imply durability, then the following table lists the specific guarantees provided by the various combinations:

If causal consistency implies durability, then, as seen from the table, only read operations with "majority" read concern and write operations with "majority" write concern can guarantee all four causal consistency guarantees. That is, causally consistent client sessions can only guarantee causal consistency for:

• Read operations with "majority" read concern; i.e. the read operations that return data that has been acknowledged by a majority of the replica set members and is durable.
• Write operations with "majority" write concern; i.e. the write operations that request acknowledgement that the operation has been applied to a majority of the replica set’s voting members.

If causal consistency does not imply durability (i.e. writes may be rolled back), then write operations with { w: 1 } write concern can also provide causal consistency.

The read concern "majority" and write concern "majority" ensure that the four causal consistency guarantees hold even in circumstances (such as with a network partition) where two members in a replica set transiently believe that they are the primary. And while both primaries can complete writes with { w: 1 } write concern, only one primary will be able to complete writes with "majority" write concern.

For example, consider a situation where a network partition divides a five member replica set:

Scenarios

To illustrate the read and write concern requirements, the following scenarios have a client issue a sequence of operations with various combination of read and write concerns to the replica set:

• Read Concern "majority" and Write concern "majority"
• Read Concern "majority" and Write concern {w: 1}
• Read Concern "local" and Write concern "majority"
• Read Concern "local" and Write concern {w: 1}

Read Concern "majority" and Write concern "majority"

The use of read concern "majority" and write concern "majority" in a causally consistent session provides the following causal consistency guarantees:

✅ Read own writes ✅ Monotonic reads ✅ Monotonic writes ✅ Writes follow reads

Scenario 1 (Read Concern “majority” and Write Concern “majority”)

During the transient period with two primaries, because only P_new can fulfill writes with { w: "majority" } write concern, a client session can issue the following sequence of operations successfully:

Sequence	Example
1. Write 1 with write concern "majority" to P new 2. Read 1 with read concern "majority" to S 2 3. Write 2 with write concern "majority" to P new 4. Read 2 with read concern "majority" to S 3	For item A, update qty to 50. Read item A. For items with qty less than or equal to 50, update restock to true. Read item A.

✅ Read own writes	Read 1 reads data from S 2 that reflects a state after Write 1. Read 2 reads data from S 1 that reflects a state after Write1 1 followed by Write 2.
✅ Monotonic reads	Read2 reads data from S3 that reflects a state after Read1.
✅ Monotonic writes	Write2 updates data on Pnew that reflects a state after Write1.
✅ Writes follow reads	Write2 updates data on Pnew that reflects a state of the data after Read1 (i.e. an earlier state reflects the data read by Read1).

Scenario 2 (Read Concern “majority” and Write Concern “majority”)

Consider an alternative sequence where Read₁ with read concern "majority" routes to S₁:

Sequence	Example
1. Write 1 with write concern "majority" to P new 2. Read 1 with read concern "majority" to S 1 3. Write 2 with write concern "majority" to P new 4. Read 2 with with read concern "majority" to S 3	For item A, update qty to 50. Read item A. For items with qty less than or equal to 50, update