Multi-region Architecture
- Pradeep P
- 4 days ago
- 3 min read
Layer 5 · Post 10 of 12
← Previous: Autoscaling → Next: Active-Active vs Active-Passive
Layer 5 — Modern infrastructure · Post 60 of 88
Multi-region architecture runs the system in more than one geographic place so users are closer and a whole region can disappear without taking you down.
What you'll learn
Why "two AZs" is not the same as "two regions"
What is easy to replicate (stateless compute) and what is hard (data)
How DNS, data gravity, and failover actually steer traffic
The idea in one minute
A region is a geographic cluster of datacenters (AWS us-east-1, ap-south-1). Multi-region means you run in more than one, on purpose.
Users --> DNS / Anycast | +--------+--------+ v v [ Region A ] [ Region B ] compute compute data? data?
Stateless app replicas are the easy part. Data — which region owns a write — is the design.
Why it matters
One region is a single blast radius: fiber cut, control-plane incident, regional IAM weirdness. Multi-AZ inside a region survives a building; it does not survive "the region is gone."
The other reason is latency. A user in Bengaluru talking to Virginia pays the ocean on every round trip. CDN (Layer 1) helps static bytes. Interactive APIs and databases need a closer region or you accept the RTT.
Interviews: do not jump to multi-region for a campus app. Do jump when the prompt is global users or "region failure is not OK."
How it works
Compute: run the same Deployments in two regions. Images are in a replicated registry. Config and secrets are per region (endpoints differ).
Traffic steering: geo-DNS, latency-based DNS, or Anycast. Health checks remove a sick region. TTL on DNS is your failover delay unless you use Anycast or a global load balancer that can flip faster.
Data patterns (this is the fork):
Primary + replica: writes in one region, reads nearby. Simple. Failover of the primary is a DR event (later posts).
Active-active data: writes in both. You need conflict rules (CRDTs, last-write-wins, or partitioned by user home region). Next post.
Pin the user: user 123's home is ap-south-1. Other regions proxy or reject. Operationally boring, often correct.
Data gravity: the database wants to sit near the writer. Shipping every write across continents adds latency and conflict. Often you replicate async (seconds of lag) and only sync what the business cannot lose.
Dependencies: if Redis, queues, and third-party APIs are still single-region, you are not multi-region — you are multi-region frontends. Map every stateful dependency.
A simple example
A read-heavy product catalog: app in Mumbai and Virginia, Postgres primary in Mumbai, read replicas in both, CDN for images. US users read locally (replica lag of a second is OK for product copy). Writes (admin edits) go to Mumbai. If Mumbai dies, you promote Virginia (DR) or serve stale reads until you do.
A payments ledger is different. You may keep a single writer region and put only the API edge near users, or you shard users by home region so a write never crosses the ocean. That is a product decision wearing an infrastructure costume.
Common mistakes
Calling three AZs "multi-region." Same region control plane, same regional outage class.
Forgetting identity and config. Auth tokens issued in A that B cannot verify. JWKS and clock skew become your incident.
Sync replication across the ocean for everything. You bought a 200ms commit. CAP is not a meme here.
DNS TTL of 300s and a 30s RTO target. The numbers do not match. Design steering to the RTO.
One global Redis "for sessions." Session store in one region makes the other region a costume.
How this shows up in real systems
Route 53 / Cloud DNS / Cloudflare Load Balancing: steering and health.
Aurora Global, Spanner, Cosmos DB, Cockroach: products that advertise cross-region writes — still with tradeoffs you should name.
Active-active vs active-passive: the operating modes — next post.
Recap
Multi-region is compute in two places plus a data story, not extra Pods in one VPC.
Steer with DNS/Anycast; match TTL and health checks to your failover goal.
Data gravity decides whether you pin writes, replicate async, or go active-active.
How those regions take traffic — both live, or one waiting — is the next distinction.
Layer 5 · Post 10 of 12
← Previous: Autoscaling → Next: Active-Active vs Active-Passive
Comments