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:

Read Concern Write Concern Read own writes Monotonic reads Monotonic writes Writes follow reads
"majority" "majority"
"majority" { w: 1 }    
"local" { w: 1 }        
"local" "majority"      

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.

Note

The other combinations of read and write concerns may also satisfy all four causal consistency guarantees in some situations, but not necessarily in all situations.

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:

Network partition: new primary elected on one side but old primary has not stepped down yet.

With the above partition

  • Writes with "majority" write concern can complete on Pnew but cannot complete on Pold.
  • Writes with { w: 1 } write concern can complete on either Pold or Pnew. However, the writes to Pold (as well as the writes replicated to S1) roll back once these members regain communication with the rest of the replica set.
  • After a successful write with "majority" write concern on Pnew, causally consistent reads with "majority" read concern can observe the write on Pnew, S2,and S3. The reads can also observe the write on Pold and S1 once they can communicate with the rest of the replica set and sync from the other members of the replica set. Any writes made to Pold and/or replicated to S1 during the partition are rolled back.

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"

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 Pnew 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.
State of data with two primaries using read concern majority and write concern majority
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 Read1 with read concern "majority" routes to S1:

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