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.