Multi-Region Topology
How many regions serve traffic, where writes are allowed, how data converges, and what the split-brain answer is.
flowchart TB
u(["Users"]) --> gslb["Global traffic manager<br/><i>health + latency routing</i>"]
subgraph ra["Region A — write primary"]
direction TB
a1["Edge + API"]
a2["Services"]
a3[("Primary DB<br/><i>accepts writes</i>")]
a1 --> a2 --> a3
end
subgraph rb["Region B — read + standby"]
direction TB
b1["Edge + API"]
b2["Services"]
b3[("Replica<br/><i>read only · lag < 2s</i>")]
b1 --> b2 --> b3
end
gslb -->|"reads: nearest"| a1
gslb -->|"reads: nearest"| b1
gslb -->|"writes: always A"| a1
b2 -.->|"write forwarding<br/>+45ms"| a2
a3 ==>|"async replication"| b3
arb{{"Failover arbitration<br/><i>manual promote · documented<br/>RPO ≤ 2s · RTO 15 min</i>"}}
arb -.-> a3
arb -.-> b3What it is
The regional picture, with the single most important annotation being where writes go. Active-active for reads with a single write region is the common and usually correct shape; genuine active-active writes require either partitioned ownership by key or conflict resolution, and the diagram must say which.
The arbitration box is the honest part. Automatic failover on a replicated database risks split brain; manual promotion costs minutes. Whichever you choose, it belongs on the page with its numbers.
When you produce it
When the availability target exceeds what one region provides, or when a regulator requires demonstrable regional independence. Before, not after, the data tier is chosen — the database's replication semantics decide what topologies are even available.
Who reads it
Executives, who are buying an RTO and an RPO. Operations, who execute the failover. Architects, who must reconcile it with the consistency model the application assumes.
What good looks like
- Write path and read path visually distinct.
- Replication mode and observed lag stated, and the resulting RPO derived from them rather than asserted.
- The failover decision is named as manual or automatic, with the split-brain reasoning.
- Cross-region latency for the forwarded write is on the diagram, because it is a user-visible cost.
- What runs warm in the secondary, and at what scale, since a cold secondary has a much longer RTO than the diagram implies.
Common mistakes
- Drawing active-active when the database has one writer.
- Asserting an RPO of zero over asynchronous replication.
- Forgetting the dependencies. A multi-region application calling a single-region identity provider is single-region.
- Never testing it, so the first real failover discovers the DNS TTL.