Multi-region gets proposed for three different reasons - availability, latency and data residency - and they have different answers. Conflating them produces architectures that are expensive, complicated and do not actually deliver what was wanted. Being precise about which problem you are solving is most of the work.
01Three problems, three architectures
If the driver is availability, you need failover, and the real question is how much data loss and downtime is acceptable. If it is latency, you need read replicas near users, which is far simpler. If it is data residency, you need data physically confined to a jurisdiction, which is a data architecture problem more than an infrastructure one.
These lead to genuinely different designs. A residency requirement is not satisfied by a global active-active cluster, and a latency problem is not solved by a passive standby that serves no traffic. Deciding which you have prevents building the wrong one expensively.
| Driver | Architecture | Relative cost |
|---|---|---|
| Availability, tolerant of minutes | Active-passive with failover | ~1.3x |
| Availability, tolerant of seconds | Active-active | ~2x+ |
| Read latency for global users | Read replicas plus CDN | ~1.2x |
| Data residency | Isolated regional stacks | ~2x, plus routing complexity |
| Regulatory continuity mandate | Tested DR with proven RTO | ~1.3x plus drill cost |
02Active-active is much harder than it sounds
Serving writes from two regions means the same record can be modified in both, and something must resolve the conflict. Last-write-wins silently discards data. Application-level resolution requires designing every entity for merge. Neither is a configuration setting.
The workloads that suit active-active are ones where writes are naturally partitioned by user or tenant, so conflicts are rare by construction. Where any user can modify any record, the complexity rises steeply and the failure modes get subtle.
03Active-passive is usually the honest answer
One region serves traffic, another stands ready with replicated data. On failure you promote the standby. Recovery is measured in minutes rather than seconds and the architecture stays comprehensible.
The trap is that a standby nobody has ever failed over to is a hypothesis. Regular, scheduled failover drills are what convert it into a capability, and they routinely uncover the missing DNS TTL, the hardcoded regional endpoint, or the replica that was silently three hours behind.
| RTO / RPO | What it requires | Cost multiplier |
|---|---|---|
| Hours / hours | Backups, documented restore | ~1.05x |
| Minutes / minutes | Warm standby, replication | ~1.3x |
| Seconds / near-zero | Active-active, sync replication | ~2x+ |
| Zero / zero | Not achievable, be honest | - |
04Data residency changes the shape entirely
Residency requirements mean data for a jurisdiction stays in that jurisdiction, which usually implies separate stacks per region rather than one global system. Users route to their region, and cross-region features - global search, aggregate reporting - become genuinely hard.
The parts teams forget are the peripheral ones: backups, logs, error tracking, analytics and support tooling all commonly ship data to a default region. A residency claim that covers the primary database but not the error tracker is not a residency claim.
05Cheaper things to try first
Multi-availability-zone within one region handles the most common failure - losing a data centre - at a fraction of the cost and complexity. A CDN with good caching solves a large share of perceived latency problems without touching the backend. Read replicas address read latency specifically.
Most organisations that believe they need multi-region need one of those three. The genuine cases - regulatory mandates, contractual availability commitments, or a real residency requirement - are worth doing properly, and everything else is worth solving more cheaply first.
Topics
Marcus Hale
Lead Architect · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.
Talk to an engineer