How would you distribute Atlas cluster nodes across regions to survive a full region outage?

## The rule is about votes, not copies A MongoDB replica set stays writable only while a **majority of voting members** can reach each other. Everything about multi-region design follows from that single sentence. Copies of your data in another region are worth nothing for availability if the members holding them cannot participate in electing a primary. The classic mistake is the two-region deployment. Put three electable members in two regions and you get a 2+1 split. Lose the region with two members and the remaining member is one vote out of three — no majority, no primary, no writes. You have paid for cross-region replication and bought yourself a read-only cluster at the moment you needed it most. The only fix is a **third region** holding at least one electable member, so any single region failure still leaves two of three votes alive. ## The node types Atlas gives you Atlas lets each region in a cluster contribute different kinds of members: - **Electable nodes** vote in elections and can become primary. Each region config carries a **priority**; the region with the highest priority is where Atlas steers the primary, and lower-priority regions take over only when it is unavailable. - **Read-only nodes** hold a full copy and serve reads, but they have no vote and can never be elected. They are how you put a local read replica in a distant region without dragging that region into your election quorum or your majority write path. - **Analytics nodes** are also non-electable read replicas, intended to isolate long-running reporting and BI queries from operational traffic. They carry a replica-set tag (`nodeType: ANALYTICS`) so a client can target them explicitly with a tagged read preference. Remember the replica-set ceiling: a set may have at most seven voting members, so "add a vote everywhere" is not an available strategy. Extra copies beyond that must be non-voting. ## What availability actually costs Spreading votes across regions buys survival and charges latency. Once a majority cannot be formed inside one region, a majority-acknowledged write must travel to another region and back before it is confirmed. Your write latency floor becomes the round trip to the nearest member that completes the majority. Choosing regions is therefore partly a geography exercise: three regions on one continent behave very differently from three spread across continents, even though both survive one region loss. This produces a real design tension that a principal-level candidate should name explicitly: - **Tight grouping** (three nearby regions) keeps writes fast and survives a regional failure, but not a wide correlated failure. - **Wide grouping** survives more, but every durable write pays a long round trip, and after a failover the primary may land far from your application tier — which changes application latency, not just database latency. - **Asymmetric designs** — two electable regions plus a small third region holding one electable member purely as a tiebreaker — are a common compromise: the tiebreaker region carries little traffic but restores the ability to form a majority. ## Multi-cloud Atlas can place members of a single replica set across AWS, Google Cloud and Azure. The reasoning is identical — it is still about where the votes are — but the failure domain being defended is a **provider**, not a region. Realistically it also serves procurement and data-residency goals, and it lets you put a read-only node close to workloads that live on another cloud. The costs are the ones you would expect: cross-provider network paths are typically slower and less predictable than intra-provider ones, egress is billed, and your operational tooling now spans three consoles. ## Where the primary should live Priority ordering is the lever that decides where writes are served from in steady state, and it deserves an explicit decision rather than a default. Put the highest priority in the region hosting your write-heavy application tier. If a failover moves the primary elsewhere, be clear about whether you want it to stay there (fewer disruptions) or migrate back (predictable latency) — the priorities encode that choice, and every failback is another election. ## Reads are a separate decision Multi-region node placement gives you the *option* of local reads, not local reads by default. Directing traffic to nearby secondaries or read-only nodes is a client-side read routing decision with its own staleness consequences, and it should be made per workload: a dashboard can tolerate lag that a checkout flow cannot. ## The judgment an interviewer wants Start from the failure you are actually defending against, not from a diagram. "Which single failure must we survive without losing writes, and what write latency will we accept to get it?" answers the topology question almost by itself: it fixes the number of vote-bearing regions, their geographic spread, and where the priority sits. Everything else — read-only nodes, analytics nodes, multi-cloud — is optimisation layered on top.