Articles · MongoDB

MongoDB Read and Write Concern Interview Questions: Acknowledgment, Visibility, and Failover

Practice MongoDB read and write concern interviews with acknowledgment, stale secondary reads, causal sessions, failover timelines, and write timeouts.

A MongoDB update succeeds, but a user immediately reads the old value. Later, a primary fails and a different acknowledged update disappears. These observations sound similar, yet one can be replication lag while the other is rollback. Your interview answer needs to distinguish them.

For MongoDB read and write concern interview questions, name three independent controls: write concern specifies acknowledgment, read concern constrains the data a read can return, and read preference selects where that read runs. A causal session connects dependent operations. None of those phrases is a substitute for drawing the actual timeline.

This guide focuses on acknowledged writes, stale observations, elections, and retries.

Evidence boundary: MongoDB’s official documentation supports the product behavior. Replica timelines and design recommendations are original exercises, not reported employer questions. No independently verified recent candidate accounts establish the frequency of these exact prompts. Unless stated otherwise, examples use a three-member replica set with three voting, data-bearing members, WiredTiger, explicit concerns, and no arbiters. Version-sensitive behavior is called out below.

Which setting answers which question?

Start with the required observation, then choose settings that support it.

Control	Question it answers	What it does not establish by itself
Write concern	What acknowledgment must this write obtain?	Every reader immediately sees the write
Read concern	Which data is eligible to be returned?	Which replica the driver selects
Read preference	Which eligible member serves the read?	The selected member has applied your preceding write
Causal session	How are this client's dependent operations ordered?	One global order for all independent clients

Official fact: Read preference controls routing. The default is primary; modes that allow secondaries may return older data because replication is asynchronous. Read preference is distinct from read concern. MongoDB read preference.

Original requirement: “After saving my profile, show the saved version on the next page.” That is a dependency between a write and a later read. “Show the newest completed update from any user” asks a stronger question. “Generate a report from one consistent point in time” asks a different one again.

Do not accept “strong consistency” as the complete requirement. Ask whose write must be visible, which documents are involved, whether reads may wait, and what should happen during a partition. Those answers make the configuration defensible.

Can a successful w:1 write disappear after failover?

Official fact: w:1 requests acknowledgment from the primary. It does not require acknowledgment from a secondary. Journaling and replication acknowledgment are separate aspects of write concern. MongoDB write concern.

Original failover exercise: Members P, S1, and S2 start with profile version 0. P accepts version 1 and acknowledges a w:1 write before either secondary receives it. P then becomes isolated. S1 and S2 can form a majority and elect a primary whose history still contains version 0.

When the old P rejoins, its divergent version 1 may be rolled back. The successful response was real; the application simply requested a contract that did not require the write to reach another member before acknowledgment.

Adding j:true to that same w:1 request does not make the new primary inherit the update. A durable record on the isolated node and a write preserved in the surviving replica-set history are different properties.

A precise answer includes the timing condition. You should not say every w:1 write is lost on election. If the write has already replicated sufficiently, the outcome can differ. The counterexample demonstrates why the acknowledgment alone is insufficient, not that failure is inevitable.

What does majority acknowledgment guarantee in MongoDB 8.0 and later?

For this three-voter example, a majority means two members. For a write requiring majority durability, state an explicit policy such as {w: "majority", j: true} when discussing the intended acknowledgment rather than relying on an unspecified deployment default.

Official fact, version-sensitive: Starting in MongoDB 8.0, majority writes can be acknowledged after a majority durably records the oplog entry; secondaries apply those entries to their collections asynchronously. Earlier releases waited for application before acknowledging. An immediate secondary read can therefore precede application even on a secondary that helped acknowledge the write. Writes and subsequent secondary reads.

Original successful-write timeline: P and S1 durably record update W. The client receives majority acknowledgment. S2 is still behind. At this point, asking whether “the database has W” is ambiguous: W is protected by the acknowledgment contract, but S2's readable collection state may still be old. In the documented 8.0 behavior, S1's application progress also matters.

This distinction prevents a common debugging mistake: treating delayed observation as proof that the majority acknowledgment was false. Check whether the symptom concerns oplog replication, collection application, or the reader's chosen view.

The exercise assumes the stated topology and durability configuration remain valid. Do not extrapolate its two-of-three arithmetic to arbiters, nonvoting members, arbitrary reconfiguration, or loss of every durable copy. In an interview, ask for those details if they affect the failure being proposed.

Why can a majority read still return an older value?

Official fact: Outside a transaction, readConcern: "majority" returns majority-committed data from the serving member's available view. It does not promise that the member reflects the newest version in the system. Transactional use has additional commit requirements. Majority read concern.

Return to the original timeline. S2 has a valid majority-committed view containing version 0, but has not caught up to W. An independent majority read routed there can return version 0. That old value can be durable and still be too old for the user's workflow.

Do not describe a majority read as “ask two replicas and choose the newest answer.” That explanation confuses the read's visibility contract with a quorum fan-out algorithm the application did not request.

Recommended answer: “Majority tells me which committed history is eligible. To ensure this read follows my preceding write, I also need to carry that dependency. Otherwise a valid older view may satisfy the concern.”

Before tuning settings, check whether the application silently used a new session, a different client, an unexpected read preference, or a cache. A database guarantee cannot account for a stale value returned entirely from an application cache.

How does a causal session provide read-your-writes?

Official fact: In a causally consistent session, majority reads together with majority writes provide read-your-writes, monotonic reads, monotonic writes, and writes-follow-reads guarantees. These guarantees depend on the combination, not on merely attaching a session object. Causal consistency and concerns.

Original implementation plan: Start an explicit causally consistent session, perform W with the intended majority write concern, wait for its successful completion, and issue the dependent majority read through that same session. Execute the dependent operations sequentially. Use your driver's session and collection options rather than copying syntax from a different driver.

If the read is routed to a lagging secondary, satisfying the dependency may require waiting for that member to catch up. Define a deadline and an application response for timeout. Do not silently weaken the read contract and present an older profile as if the save never happened.

For a workflow crossing services, “we both use sessions” is not enough. Explain how causal context is propagated through supported mechanisms, or choose a design that keeps the dependent operations together. A new unrelated session does not automatically know the first service's completed write.

Causality also does not eliminate concurrent updates. If another client writes a newer profile, a later read may legitimately return that newer version. “Read my writes” means the read respects the dependency, not that it freezes the document at exactly the value you last submitted.

Does a write concern timeout undo the update?

Official fact: A write concern timeout reports that the requested acknowledgment was not obtained in time. MongoDB does not undo the successful primary-side changes merely because that wait expires; replication may continue afterward. Write concern timeout behavior.

Original scenario: A request increments a document's revision counter. P applies the increment, but the majority acknowledgment deadline expires. The application starts a fresh increment request because it interprets the error as “nothing happened.” If both operations ultimately persist, the counter advances twice.

Separate the mutation outcome from the acknowledgment outcome. Preserve a stable application operation ID, inspect the error details, and reconcile uncertain results through a design that can recognize an already-applied operation. A missing value from one stale read does not prove the first attempt never ran.

Official fact: Driver retryable writes cover supported operations and specific failure conditions; they require a compatible deployment and acknowledged writes. Writes inside a transaction are not individually retryable through that mechanism. Retryable writes.

Distinguish a supported driver retry of the same logical operation from a brand-new business request issued by application code. Avoid describing the feature as unlimited, universal exactly-once execution. It cannot deduplicate arbitrary external side effects or an unrelated HTTP request created later.

Recommended design exercise: For a profile change, store a stable operation identifier with the state transition and enforce deduplication atomically at the appropriate boundary. If the deduplication record and mutation can diverge, the identifier alone is only a log label. Explain how the caller retrieves the original outcome after a lost response.

When are linearizable reads or snapshots the better fit?

Official fact: Linearizable read concern, combined with majority writes, supports real-time ordering for a uniquely identified single document. It runs on the primary, has restrictions, and should use maxTimeMS so loss of the required availability does not cause an unbounded wait. It is unavailable in causally consistent sessions. Linearizable read concern.

Original requirement: An independent administrator must read a particular configuration document after another administrator's completed update. If real-time ordering is required, discuss linearizable semantics and their availability cost instead of assuming the reader shares the writer's causal session.

Official fact: Snapshot read concern provides a view at one point in time. For transaction guarantees, the transaction must commit with majority write concern; supported reads outside transactions have their own rules. Snapshot read concern.

A snapshot is useful when the question is internal consistency across related observations. It is not shorthand for “the latest possible value.” Choose the contract from the application's invariant, then discuss transaction scope, deadlines, and handling of failed attempts.

Interview requirement	Contract to discuss	Follow-up you should expect
Preserve a write through the stated replica failure	Majority acknowledgment and durability assumptions	Which members acknowledged, and which copies survived?
Read a preceding session write from a secondary	Causal session plus majority read/write concerns	Can the read wait for application progress?
Order an independent single-document read after completed writes	Linearizable read and majority writes	What happens when a majority is unavailable?
Observe related data at one consistent time	Snapshot semantics and transaction boundaries	Is recency or consistency the actual requirement?

Sources and Further Reading

Research checked September 21, 2026. Product behavior and supported settings can vary by version and deployment.