Challenge 2: Choose a Read Preference — Possible Solution
====================================================================

(a) Nightly sales report query — secondary (or secondaryPreferred).
This is exactly the chapter's canonical example: a reporting query
that runs once a day can easily tolerate being a few seconds (or even
minutes) behind real-time, and routing it to a secondary keeps that
potentially heavy aggregation load off the primary, which needs to
stay responsive for live writes.

(b) Reading a user's profile immediately after they update it —
primary. This is a read-your-own-writes situation: the user just wrote
new data and expects to see it reflected back immediately. If this
read went to a secondary, replication lag could mean the user sees
their OLD profile data right after saving — a confusing, visibly wrong
result, even though the write itself succeeded correctly on the
primary.

(c) A customer-facing "check my order status" page — primary (or, if
lag is known to be very low and a slight delay is acceptable,
primaryPreferred as a middle ground). An order status is exactly the
kind of value where staleness reads as a real, visible bug — a
customer seeing "Processing" when the order actually shipped an hour
ago erodes trust in the page. Unlike (a), there's no accompanying
"acceptable to be a bit behind" business justification here, so
defaulting to primary is the safer choice.