What happens to a running application while an Atlas cluster tier change is applied?

## The change is a rolling replacement When you move an Atlas cluster from one tier to another — by hand or via auto-scaling — Atlas does not grow a running machine. It performs a **rolling** change across the replica set: one member at a time is replaced or resized and brought back into sync, while the remaining members continue to serve the workload and preserve a majority. Only when the secondaries are done does Atlas deal with the primary, and the only way to replace a primary is to stop it being the primary. So Atlas issues a **step-down**, an election runs, a resized secondary is elected, and the old primary is replaced last. That sequence has one unavoidable consequence: there is a short interval with **no primary**. Elections complete in seconds on a healthy cluster, but during that interval every write and every primary-targeted read has nowhere to go. ## What the application sees From the driver's point of view, the primary disappears and a new one appears somewhere else in the set. Concretely: - In-flight writes to the old primary fail with a "not primary" style error. - New operations block in server selection until a primary is discovered again. - Connections to the replaced member are closed, so the pool must re-establish them. Modern drivers handle all of this **if you let them**. Retryable writes cause the driver to transparently retry a single-statement write once against the new primary; retryable reads do the same for reads. Both are on by default in current drivers, and the Atlas-provided connection string includes `retryWrites=true`. Server selection has its own timeout — leave enough of it that an election fits inside the window instead of surfacing as an error to your users. An `mongodb+srv://` connection string matters too: it resolves the seed list through DNS and lets the driver discover topology changes, rather than pinning your application to hostnames that a resize may invalidate. ## The cold-cache tail The part people forget is what happens *after* the election succeeds. MongoDB's performance is dominated by whether the working set sits in the WiredTiger cache and the operating system page cache. A newly provisioned or restarted member starts with both empty. So immediately after a tier change, the new primary serves reads from disk, p99 latency climbs, and the cluster looks *worse* than the tier you left — sometimes for minutes on a large working set. This inverts the naive expectation ("I scaled up, so it should be fast now") and it is the reason a scale-up during peak traffic can make an incident worse before it makes it better. It is also why scaling **down** under load is genuinely dangerous: you simultaneously shrink the cache and empty it, while traffic is unchanged. ## Making a resize safe The checklist a senior engineer should produce: 1. **Retries on.** Retryable writes and retryable reads enabled; application-level operations idempotent where a retry could duplicate work. 2. **SRV connection string**, no hard-coded hosts, no cached DNS beyond its TTL. 3. **Timeouts that span an election.** Server-selection timeout comfortably larger than a normal election; sensible client-side operation timeouts so a stalled request fails predictably instead of piling up. 4. **Back-pressure.** A brief period with no primary means requests queue. Bounded pools and fast failure beat unbounded queueing, which turns a five-second election into a minute-long recovery as a thundering herd reconnects. 5. **Timing.** Deliberate resizes go in a low-traffic window. Auto-scaling can fire at any time, which is a reason to test the behaviour rather than hope. 6. **Watch the tail.** Measure latency for a while after the change; do not declare success at the moment the console says the cluster is healthy. ## Multi-region and larger topologies On a multi-region cluster the election has an extra dimension: the member that wins may sit in a different region from the one that just stepped down, which changes the latency your writers see and the round trip that a majority acknowledgement requires. If a specific region should hold the primary, member priorities need to reflect that so the cluster settles back where you intended rather than staying wherever the election landed. ## The interview framing The naive answer is "nothing, Atlas handles it, it's zero downtime". The accurate answer is "it is *near*-zero downtime, and only because the driver retries for you". Saying that out loud — plus the cold-cache tail — is what separates someone who has resized a production cluster from someone who has read the marketing page.