How would you configure a MongoDB replica set to meet a strict limit on write unavailability during failover?

## Reframe the question first "Make failover faster" is usually answered with "lower `electionTimeoutMillis`", which is a partial answer that trades one problem for another. The productive framing is: **what is the client-visible write-unavailable window made of, and which parts can I actually shrink?** There are four sequential phases. **1. Detection.** Members heartbeat each other on `heartbeatIntervalMillis` (default `2000`). A secondary that goes `electionTimeoutMillis` (default `10000`) without successful contact with the primary concludes the primary is gone. On a default configuration this phase is most of the outage. **2. Voting.** The candidate solicits votes and needs a strict majority of voting members. This is roughly one round trip, and it is bounded not by the average latency among voters but by the latency to the slowest member of whichever majority answers. Where the voters sit therefore directly sets this cost. **3. Catch-up.** The elected primary attempts to apply oplog entries other members hold and it does not, before accepting writes, so that as little history as possible is discarded. `catchUpTimeoutMillis` bounds this phase. A well-replicated set spends almost no time here; a set with a lagging secondary can spend a lot. **4. Client rediscovery.** Drivers monitor topology on their own interval. Until the driver learns of the new primary, operations wait in server selection and eventually fail against the driver's server-selection timeout. This phase is invisible from the server side and is frequently the part teams forget. ## Levers, in the order they usually pay **Enable retryable writes.** This is the highest-leverage change and it is client-side. With retryable writes, a write that fails because the primary went away is retried once after the driver re-selects a server. A single failover then shows up as one slow request rather than an error surfaced to the user. It does not shorten the server-side window, but it changes what the window *means* to the application — which is what the availability target is actually about. **Place the voters for fast agreement.** Voting latency is set by the slowest member of the majority. Voters spread across distant regions make every election slow and also make aggressive detection timeouts unsafe. Keep the voting members on a low-latency network with each other; put distant copies in as `priority: 0` (and, if you want them out of the arithmetic entirely, `votes: 0`) members. **Use an odd number of voters.** Even counts add a voter without adding fault tolerance and create a symmetric-split shape in which nobody has a majority and the set is write-unavailable indefinitely — an unbounded outage, which no timeout tuning can fix. **Avoid arbiters.** An arbiter buys a vote and nothing else. In a primary-secondary-arbiter set, losing the single secondary leaves majority write concern unsatisfiable and the majority commit point frozen, which degrades the surviving primary over time. A third data-bearing member costs a machine and removes that entire class of incident. **Keep secondaries caught up.** Replication lag lengthens the catch-up phase and widens the set of writes exposed to rollback. Lag is worth monitoring specifically as a failover-readiness signal, not only as a read-staleness signal. **Tune `electionTimeoutMillis` last, and only with evidence.** Lowering it shortens detection but makes GC pauses, disk stalls and latency spikes look like a dead primary. Each false positive costs another outage window and risks rolling back writes acknowledged only by the old primary. Lower it only where you have measured the tail latency between voters and have headroom. **Use `w: "majority"` on writes that matter.** This does not shorten the outage. It ensures the outage does not also silently lose acknowledged writes, which is usually the more expensive failure. ## Steering where the primary lands `members[n].priority` biases which member the set converges on, so you can keep the primary in the region holding most of the clients. Two cautions. A priority change is not passive — a higher-priority secondary calls a takeover election as soon as it is caught up, producing a real failover at the moment you run the reconfig. And a flapping high-priority node will pull the primary back to itself repeatedly, turning one bad machine into a series of outages. Priority steers; it does not guarantee. ## Measure, don't model The only credible number is a measured one. Rehearse with `rs.stepDown()` on the primary under production-shaped load, and instrument the *client*: time from step-down to the first successful write from the application, not from the server logs. A planned step-down is the optimistic case because it includes a catch-up courtesy period; also rehearse the pessimistic case by hard-stopping a primary in a non-production environment, where detection runs the full timeout. Run this regularly rather than once. Voter placement drifts, drivers get upgraded, lag profiles change with load. A failover budget that was verified a year ago is a claim, not a measurement. ## What to say about the trade-off The honest summary is that you can compress the outage to a few seconds with careful placement and a modestly reduced timeout, and you can make most of that invisible to users with retryable writes — but you cannot drive it to zero, and pushing detection too hard converts a rare outage into frequent ones. If the requirement is genuinely zero write unavailability, the answer is not replica set tuning; it is a change in what the application does during the window, such as queueing or degrading gracefully.