A service writes an order with `w: "majority"` then immediately reads it back from a secondary with `readPreference: "secondary"` to confirm it was saved — and sometimes the read comes back empty. The write concern was already majority; why does the read still miss it, and what actually fixes it?

Write concern and read preference answer two unrelated questions: w: "majority" says how durable the write is before the driver reports success; readPreference: "secondary" says which member answers the read, and secondaries apply the oplog with lag, so a secondary can simply not have replicated this specific write yet, majority-durable or not — durability and replication lag are separate properties, and a durable write can still be seconds away from showing up on a given secondary. A plain, uncoordinated read from a secondary has no way to know it should wait. The fix is a ClientSession used for both operations: the driver attaches the write's timestamp to the session, and a causally-consistent read in that same session waits until the secondary it's routed to has caught up to at least that timestamp before answering — read-your-own-writes as a property of the session, not something w: "majority" or a plain read preference provides on their own.