Why should you care?

Heavy analytics can read from secondaries so the primary keeps serving checkout writes.

See it live — copy this example

Open mongosh or MongoDB Compass, select database nosqlverse, then run the example. Change one field and run again.

// mongosh
db.getMongo().setReadPref("secondaryPreferred")
db.orders.find({ tenantId: "acme" }).limit(5)
// Node driver URI option: ?readPreference=secondaryPreferred
// or collection.find(q).withReadPreference(ReadPreference.secondary)

Run Example »

Edit the code below and click Run to see the result in Toolliyo’s live editor.

What happened?

• secondaryPreferred tries a secondary, falling back to primary if needed.
• Stale reads are possible because replication lags.
• Do not use secondary reads for read-your-writes checkout confirmation without care.

Practice next

1. Set read pref secondaryPreferred in mongosh on a replica set.
2. Run a find and check which host served it if possible.
3. List which APIs can tolerate lag.
4. Try nearest for multi-region apps.
5. Combine with maxStalenessSeconds in drivers.

Remember

Read preference chooses read targets. Secondaries may be slightly stale. Use for analytics and heavy reads.

Report reads vs checkout writes

Seller reports use secondaryPreferred; place-order uses primary.

Outcome: Dashboards scale out without starving purchases.