Read concern levels (local, majority, snapshot) in MongoDB - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ query_result

intermediate

Output of a query with read concern 'local'

Consider a MongoDB collection orders where a document was just inserted but not yet replicated to secondaries. What will be the result of this query with readConcern: 'local'?

db.orders.find({}).readConcern('local').toArray()

MongoDB

db.orders.find({}).readConcern('local').toArray()

A Returns only documents that are replicated to the majority of nodes

B Returns the newly inserted document immediately, even if not replicated

C Returns documents only from a stable snapshot at the start of the query

D Throws an error because 'local' is not a valid read concern

💡 Hint

Think about what 'local' means: reading from the node's own data without waiting for replication.

The 'local' read concern returns data from the node's own view, including unreplicated writes. It does not wait for replication.

❓ query_result

intermediate

Effect of read concern 'majority' on query results

In a MongoDB replica set, a document was inserted but has not yet been replicated to the majority of nodes. What will a query with readConcern: 'majority' return?

db.orders.find({}).readConcern('majority').toArray()

MongoDB

db.orders.find({}).readConcern('majority').toArray()

A Returns the document immediately regardless of replication

B Returns an empty array if the document is not replicated yet

C Returns the document only after it is replicated to the majority of nodes

D Returns documents from a snapshot taken at the query start time

💡 Hint

Consider what 'majority' means for data visibility in a replica set.

The 'majority' read concern ensures that the query returns data that has been acknowledged by the majority of replica set members, so unreplicated writes are not visible yet.

❓ query_result

advanced

Behavior of read concern 'snapshot' in a multi-document transaction

Within a multi-document transaction using readConcern: 'snapshot', what is the visibility of data changes made outside the transaction after it started?

MongoDB

session.startTransaction({readConcern: {level: 'snapshot'}});
db.orders.find({}).toArray();

A The query sees a consistent snapshot of data as of the transaction start, ignoring outside changes

B The query sees the latest data including changes made after the transaction started

C The query fails because 'snapshot' is not allowed in transactions

D The query returns only documents committed before the last checkpoint

💡 Hint

Think about what 'snapshot' read concern guarantees inside transactions.

'Snapshot' read concern provides a stable view of data as it existed at the start of the transaction, so changes made outside after the start are not visible.

🧠 Conceptual

advanced

Choosing read concern for low latency vs. data consistency

You want to design a MongoDB application that prioritizes the fastest possible reads, even if it means reading unreplicated or stale data. Which read concern level should you choose?

A 'snapshot' because it provides a consistent view of data in transactions

B 'majority' because it ensures data is replicated to most nodes before reading

C 'linearizable' because it guarantees the most up-to-date data

D 'local' because it reads from the node's current data without waiting for replication

💡 Hint

Consider which read concern returns data fastest without waiting for replication.

'Local' read concern returns data immediately from the node's own view, providing the lowest latency but possibly reading unreplicated data.

🧠 Conceptual

expert

Impact of read concern 'majority' on read availability during network partitions

During a network partition in a MongoDB replica set, which of the following best describes the behavior of queries using readConcern: 'majority'?

A Queries may block or fail if the node cannot confirm majority replication

B Queries return data from the primary immediately regardless of replication

C Queries return stale data from secondaries without waiting for majority

D Queries automatically downgrade to 'local' read concern to maintain availability

💡 Hint

Think about how 'majority' read concern depends on replication acknowledgments.

'Majority' read concern requires confirmation that data is replicated to most nodes. During partitions, this may cause queries to block or fail if majority cannot be confirmed.

Practice

1. Which MongoDB read concern level provides the fastest read but may return data that is not yet acknowledged by majority of nodes?

easy

A. local

B. majority

C. snapshot

D. linearizable

Solution

1. Step 1: Understand read concern levels

   local returns the most recent data on the node but does not wait for replication.

2. Step 2: Compare with other levels

   majority waits for data to be acknowledged by majority nodes, snapshot is for transactions, and linearizable is stricter and slower.

3. Final Answer:

   local -> Option A

4. Quick Check:

   Fastest read = local [OK]

Hint: Fastest read is always local [OK]

Common Mistakes:

• Confusing local with majority
• Thinking snapshot is fastest
• Assuming linearizable is default

2. Which of the following is the correct syntax to set read concern to majority in a MongoDB query?

easy

A. db.collection.find.readConcern('majority')

B. db.collection.find().readConcern = 'majority'

C. db.collection.find().readConcern('majority')

D. db.collection.find().withReadConcern('majority')

Solution

1. Step 1: Recall MongoDB read concern syntax

   The correct method to set read concern on a query is readConcern('level').

2. Step 2: Check options for syntax correctness

   Some options look similar, but one omits parentheses after find. The correct chaining is db.collection.find().readConcern('majority').

3. Final Answer:

   db.collection.find().readConcern('majority') -> Option C

4. Quick Check:

   Correct method call = db.collection.find().readConcern('majority') [OK]

Hint: Use .readConcern('level') after find() [OK]

Common Mistakes:

• Using assignment instead of method call
• Using non-existent method names
• Placing parentheses incorrectly

3. Given a MongoDB transaction using snapshot read concern, what will be the behavior if a document is updated after the transaction starts but before it reads the document?

medium

A. The transaction reads the updated document reflecting the change.

B. The transaction reads the document state as it was at the start of the transaction.

C. The transaction throws an error due to data inconsistency.

D. The transaction reads the document from the primary node only.

Solution

1. Step 1: Understand snapshot read concern in transactions

   snapshot ensures a consistent view of data as of the start of the transaction.

2. Step 2: Analyze document update timing

   Since the document was updated after the transaction started, the transaction will not see this change.

3. Final Answer:

   The transaction reads the document state as it was at the start of the transaction. -> Option B

4. Quick Check:

   snapshot = consistent start view [OK]

Hint: Snapshot reads see data as of transaction start [OK]

Common Mistakes:

• Assuming transaction sees latest updates
• Thinking snapshot causes errors on updates
• Confusing snapshot with majority read concern

4. You wrote this code snippet to set read concern to majority but it throws an error:

db.collection.find().readConcern = 'majority'

What is the error and how to fix it?

medium

A. No error, code is correct.

B. Error: readConcern must be set on the client, not query.

C. Error: 'majority' is not a valid read concern level.

D. Error: readConcern is a method, use readConcern('majority') instead.

Solution

1. Step 1: Identify the error cause

   Assigning a string to readConcern property is invalid because it is a method, not a property.

2. Step 2: Correct the syntax

   Use method call syntax: readConcern('majority') to set the read concern level.

3. Final Answer:

   Error: readConcern is a method, use readConcern('majority') instead. -> Option D

4. Quick Check:

   Use method call, not assignment [OK]

Hint: Use parentheses for readConcern, not assignment [OK]

Common Mistakes:

• Assigning string instead of calling method
• Setting read concern on wrong object
• Using invalid read concern levels

5. You want to ensure your MongoDB transaction reads a consistent snapshot of data and also that your reads outside transactions see only data confirmed by majority of nodes. Which read concern levels should you use respectively?

hard

A. snapshot for transactions, majority for outside reads

B. local for transactions, snapshot for outside reads

C. majority for transactions, local for outside reads

D. snapshot for transactions, local for outside reads

Solution

1. Step 1: Identify read concern for transactions

   snapshot read concern ensures consistent view inside transactions.

2. Step 2: Identify read concern for outside transactions

   majority ensures reads see data confirmed by majority of nodes, providing safety.

3. Final Answer:

   snapshot for transactions, majority for outside reads -> Option A

4. Quick Check:

   Transaction = snapshot, Outside = majority [OK]

Hint: Use snapshot in transactions, majority outside [OK]

Common Mistakes:

• Using local inside transactions
• Confusing majority with snapshot
• Using local for safe reads