# Multi-region cluster
## Setup
When creating the cluster (or modifying it), add regions with node roles:
- One region holds the primary-eligible nodes with highest priority: your main region, closest to the app.
- Additional regions hold electable nodes with lower priority, or read-only nodes for local reads.
- Reads can use `nearest` read preference for region-local latency; writes always go to the primary wherever it is.
## Rules
- Region priority decides where the primary lives. Set it explicitly; the default may not match your latency goals.
- Cross-region replication adds write latency (majority write concern spans regions). Measure it; do not assume it is free.
- Data transfer between regions costs money on dedicated tiers. Model it before you multi-region everything.
- Keep an odd total of electable nodes across regions for clean elections.
## Failover test (do this before you need it)
1. In staging, simulate the primary region failing (Atlas lets you test failover).
2. Watch election: a new primary should be elected in another region within seconds to a minute.
3. Confirm the app reconnects (drivers handle elections; check your retry and timeout settings) and writes resume.
4. Measure the latency and error blip so the incident runbook has real numbers.
## Verify
The app serves from the surviving regions with the measured blip, and Atlas shows a healthy new primary. Document the runbook with the actual timings.