• MongoDB CRUD Operations >
• MongoDB CRUD Concepts >
• Read Isolation, Consistency, and Recency >
• Causal Consistency and Read and Write Concerns

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:

With the above partition

• Writes with "majority" write concern can complete on P_new but cannot complete on P_old.
• Writes with { w: 1 } write concern can complete on either P_old or P_new. However, the writes to P_old (as well as the writes replicated to S₁) roll back once these members regain communication with the rest of the replica set.
• After a successful write with "majority" write concern on P_new, causally consistent reads with "majority" read concern can observe the write on P_new, S₂,and S₃. The reads can also observe the write on P_old and S₁ 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 P_old and/or replicated to S₁ 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"
• 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. Write1 with write concern "majority" to Pnew 2. Read1 with read concern "majority" to S2 3. Write2 with write concern "majority" to Pnew 4. Read2 with read concern "majority" to S3	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	Read1 reads data from S2 that reflects a state after Write1. Read2 reads data from S1 that reflects a state after Write11 followed by Write2.
✅ 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. Write1 with write concern "majority" to Pnew 2. Read1 with read concern "majority" to S1 3. Write2 with write concern "majority" to Pnew 4. Read2 with with read concern "majority" to S3	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.

In this sequence, Read₁ cannot return until the majority commit point has advanced on P_old. This cannot occur until P_old and S₁ can communicate with the rest of the replica set; at which time, P_old has stepped down (if not already), and the two members sync (including Write₁) from the other members of the replica set.

✅ Read own writes	Read1 reflects a state of data after Write11, albeit after the network partition has healed and the member has sync’ed from the other members of the replica set. Read2 reads data from S3 that reflects a state after Write11 followed by Write2.
✅ Monotonic reads	Read2 reads data from S3 that reflects a state after Read1 (i.e. an earlier state is reflected in the data read by 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).

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

The use of read concern "majority" and write concern { w: 1 } in a causally consistent session provides the following causal consistency guarantees if causal consistency implies durability:

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

If causal consistency does not imply durability:

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

Scenario 3 (Read Concern “majority” and Write Concern {w: 1})

During the transient period with two primaries, because both P_old and P_new can fulfill writes with { w: 1 } write concern, a client session could issue the following sequence of operations successfully but not be causally consistent if causal consistency implies durability:

Sequence	Example
1. Write1 with write concern { w: 1 } to Pold 2. Read1 with read concern "majority" to S2 3. Write2 with write concern { w: 1 } to Pnew 4. Read2 with with read concern "majority" to S3	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.

In this sequence,

• Read₁ cannot return until the majority commit point has advanced on P_new past the time of Write₁.
• Read₂ cannot return until the majority commit point has advanced on P_new past the time of Write₂.
• Write₁ will roll back when the network partition is healed.

➤ If causal consistency implies durability

❌ Read own writes	Read1 reads data from S2 that does not reflect a state after Write1.
✅ Monotonic reads	Read2 reads data from S3 that reflects a state after Read1 (i.e. an earlier state is reflected in the data read by Read1).
❌ Monotonic writes	Write2 updates data on Pnew that does not reflect a state after Write1.
✅ Writes follow reads	Write2 updates data on Pnew that reflects a state after Read1 (i.e. an earlier state reflects the data read by Read1).

➤ If causal consistency does not imply durability

✅ Read own writes	Read1 reads data from S2 returns data that reflects a state equivalent to Write1 followed by rollback of Write1.
✅ Monotonic reads	Read2 reads data from S3 that reflects a state after Read1 (i.e. an earlier state is reflected in the data read by Read1).
✅ Monotonic writes	Write2 updates data on Pnew that is equivalent to after Write1 followed by rollback of Write1.
✅ Writes follow reads	Write2 updates data on Pnew that reflects a state after Read1 (i.e. whose earlier state reflects the data read by Read1).

Scenario 4 (Read Concern “majority” and Write Concern {w: 1})

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

Sequence	Example
1. Write1 with write concern { w: 1 } to Pold 2. Read1 with read concern "majority" to S1 3. Write2 with write concern { w: 1 } to Pnew 4. Read2 with with read concern "majority" to S3	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.

In this sequence:

• Read₁ cannot return until the majority commit point has advanced on S₁. This cannot occur until P_old and S₁ can communicate with the rest of the replica set. At which time, P_old has stepped down (if not already), Write₁ is rolled back from P_old and S₁, and the two members sync from the other members of the replica set.

➤ If causal consistency implies durability

❌ Read own writes	The data read by Read1 does not reflect the results of Write1, which has rolled back.
✅ Monotonic reads	Read2 reads data from S3 that reflects a state after Read1 (i.e. whose earlier state reflects the data read by Read1).
❌ Monotonic writes	Write2 updates data on Pnew that does not reflect a state after Write1, which had preceded Write2 but has rolled back.
✅ Writes follow reads	Write2 updates data on Pnew that reflects a state after Read1 (i.e. whose earlier state reflects the data read by Read1).

➤ If causal consistency does not imply durability

✅ Read own writes	Read1 returns data that reflects the final result of Write1 since Write1 ultimately rolls back.
✅ Monotonic reads	Read2 reads data from S3 that reflects a state after Read1 (i.e. an earlier state reflects the data read by Read1).
✅ Monotonic writes	Write2 updates data on Pnew that is equivalent to after Write1 followed by rollback of Write1.
✅ Writes follow reads	Write2 updates data on Pnew that reflects a state after Read1 (i.e. an earlier state reflects the data read by Read1).

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

The use of read concern "local" and write concern { w: 1 } in a causally consistent session cannot guarantee causal consistency.

❌ Read own writes ❌ Monotonic reads ❌ Monotonic writes ❌ Writes follow reads

This combination may satisfy all four causal consistency guarantees in some situations, but not necessarily in all situations.

Scenario 5 (Read Concern “local” and Write Concern {w: 1})

During this transient period, because both P_old and P_new can fulfill writes with { w: 1 } write concern, a client session could issue the following sequence of operations successfully but not be causally consistent:

Sequence	Example
1. Write1 with write concern { w: 1 } to Pold 2. Read1 with read concern "local" to S1 3. Write2 with write concern { w: 1 } to Pnew 4. Read2 with read concern "local" to S3	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	Read2 reads data from S3 that only reflects a state after Write2 and not Write1 followed by Write2.
❌ Monotonic reads	Read2 reads data from S3 that does not reflect a state after Read1 (i.e. an earlier state does not reflect the data read by Read1).
❌ Monotonic writes	Write2 updates data on Pnew that does not reflect a state after Write1.
❌ Write follow read	Write2 updates data on Pnew that does not reflect a state after Read1 (i.e. an earlier state does not reflect the data read by Read1).

Read Concern "local" and Write concern "majority"

The use of read concern "local" 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

This combination may satisfy all four causal consistency guarantees in some situations, but not necessarily in all situations.

Scenario 6 (Read Concern “local” and Write Concern “majority”)

During this transient period, because only P_new can fulfill writes with { w: "majority" } write concern, a client session could issue the following sequence of operations successfully but not be causally consistent:

Sequence	Example
1. Write1 with write concern "majority" to Pnew 2. Read1 with read concern "local" to S1 3. Write2 with write concern "majority" to Pnew 4. Read2 with read concern "local" to S3	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.	Read1 reads data from S1 that does not reflect a state after Write11.
❌ Monotonic reads.	Read2 reads data from S3 that does not reflect a state after Read1 (i.e. an earlier state does not reflect the data read by Read1).
✅ Monotonic writes	Write2 updates data on Pnew that reflects a state after Write1.
❌ Write follow read.	Write2 updates data on Pnew that does not reflect a state after Read1 (i.e. an earlier state does not reflect the data read by Read1).

←   Read Isolation, Consistency, and Recency Distributed Queries  →

© MongoDB, Inc 2008-present. MongoDB, Mongo, and the leaf logo are registered trademarks of MongoDB, Inc.