Read from secondaries trade-offs in MongoDB - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Read Preference Impact

In MongoDB, what is a primary trade-off when configuring an application to read from secondary replicas instead of the primary?

A Secondary nodes cannot serve any read requests.

B Writes become slower because secondaries handle write operations.

C The primary node becomes unavailable for reads.

D Reads may return stale data due to replication lag.

💡 Hint

Think about how data replication timing affects read freshness.

Reading from secondaries can cause the application to see outdated data because secondaries replicate data asynchronously and may lag behind the primary.

❓ query_result

intermediate

Result of Reading from Secondary with Lag

Given a MongoDB replica set where the secondary is 5 seconds behind the primary, what is the expected behavior when a read query is sent with read preference set to 'secondary' immediately after a write on the primary?

MongoDB

db.collection.insertOne({item: 'book', qty: 10});
// Immediately after, a read with readPreference: 'secondary' is performed

A The read returns the document only after the secondary catches up, causing a delay.

B The read returns the newly inserted document immediately.

C The read fails because secondaries do not accept reads.

D The read returns an error due to replication lag.

💡 Hint

Consider how replication delay affects data visibility on secondaries.

Since the secondary is behind by 5 seconds, it will not have the new document until it replicates the write from the primary, causing a delay in visibility.

❓ optimization

advanced

Optimizing Read Latency with Secondary Reads

Which strategy best reduces read latency when using secondary reads in a geographically distributed MongoDB replica set?

A Configure read preference to 'nearest' to read from the closest secondary node.

B Always read from the primary to ensure data freshness.

C Disable replication to avoid lag.

D Use read preference 'primaryPreferred' to read only from the primary.

💡 Hint

Think about how network distance affects latency.

Using 'nearest' read preference allows the application to read from the closest replica, reducing network latency and improving read performance.

🔧 Debug

advanced

Diagnosing Stale Data Reads

An application reads from secondaries but notices stale data frequently. Which MongoDB feature can help reduce stale reads without sacrificing availability?

A Disable secondary reads and read only from primary.

B Increase write concern to 'w: 0' to speed up writes.

C Use 'readConcern' set to 'majority' to ensure data is acknowledged by most nodes.

D Set read preference to 'primaryPreferred' to always read from primary.

💡 Hint

Consider how read concern affects data consistency.

'readConcern: majority' ensures that reads return data that has been acknowledged by a majority of replica set members, reducing stale reads while still allowing reads from secondaries.

🧠 Conceptual

expert

Trade-offs of Reading from Secondaries in High Write Workloads

In a MongoDB replica set with heavy write traffic, what is a key trade-off when enabling reads from secondaries to scale read throughput?

A Secondary nodes reject all read requests to maintain consistency.

B Increased risk of reading outdated data due to replication lag, but improved read scalability.

C Writes become slower because secondaries handle write operations.

D Primary node becomes a bottleneck for all reads and writes.

💡 Hint

Think about how replication lag affects read freshness and system scalability.

Reading from secondaries improves read scalability but can cause applications to see stale data because secondaries lag behind the primary during heavy write loads.