Going multi-region is the moment your architecture decisions stop being theoretical. This post is the working playbook for SaaS in 2026.

Why multi-region

Three real reasons:

  1. Latency. Users in Bangalore on a US-East server pay 250ms RTT. Local serving is 30ms.
  2. Data residency. EU customers’ data must stay in EU (GDPR + customer demand).
  3. Disaster recovery. One region fails; another takes over.

Any one of these is enough to justify the cost. None of them: stay single-region.

Tenant pinning — the simple model

Each customer’s data lives in one region. They sign up; pick a region (or default by IP); their data lives there forever.

User logs in
  ↓
Auth service looks up tenant's home region
  ↓
Routes to that region's stack
  ↓
Region serves all reads and writes locally
  • Simple: each region is a complete deployment.
  • Fast: all data local; no cross-region latency.
  • Compliant: EU data stays in EU.
  • Limitation: tenant can’t operate cross-region without explicit migration.

For 95% of B2B SaaS, this is the right model.

Routing

Two patterns:

DNS-based

Each region has its own subdomain: eu.app.example.com, us.app.example.com. Login redirects to the tenant’s region.

Path-based with edge router

app.example.com/* hits a global edge router (Cloudflare Worker, edge Lambda). It looks up the tenant; routes to the right region.

For Cloudflare Workers Durable Objects fit perfectly — one DO per tenant; lives in the right region.

Postgres patterns

Per-region primary

Each region has its own Postgres primary. Tenants are pinned. Cross-region replicas exist for DR / failover.

US:  primary (writes) + EU replica (read for cross-region needs)
EU:  primary (writes) + US replica
APAC: primary (writes) + cross-region replicas

For Postgres replication patterns .

Cross-region failover

If US primary dies: promote US replica in EU; users see brief degradation; failover within minutes.

DR runbook: practice it monthly. Untested failover doesn’t work.

Read replicas in non-home region

For tenants with users in multiple regions, a read replica in those regions lets reads stay local. Writes still go to home.

Application routes: writes to home region; reads to local replica with eventual consistency tolerated.

Data residency

For EU customers requiring data residency:

  • Tenant in EU region.
  • No cross-region replication of their data outside EU.
  • CDN at EU edge only for their assets.
  • Backups in EU.
  • Audit log of any cross-region access.

Engineering for this isn’t free. Charge for it (enterprise tier).

Global state

Some data is genuinely global: user identity, billing, feature flags. Two patterns:

Eventually consistent

Single global Postgres in one region; replicas everywhere. Writes go to the central; reads can be slightly stale.

Most “global” data tolerates this — feature flags, billing usage records.

Distributed SQL

CockroachDB / Spanner / Yugabyte. True multi-region writes. See Distributed SQL in 2026 .

Costs: more ops, higher latency, more complexity. Use when tenant data is genuinely global (collaborative editing, financial trading).

Deploys

Deploy regions independently. Roll out a feature region-by-region for blast-radius control.

1. Deploy to EU staging.
2. Deploy to EU prod (small region).
3. Watch SLOs. ([SLOs and Error Budgets](https://blog.rajpoot.dev/posts/devops/slos-error-budgets-sre-app-developers/))
4. Deploy to US prod.
5. Deploy to APAC.

Region-aware GitOps (Argo CD ApplicationSet with cluster generator).

Latency budget

For a multi-region app, the latency dance:

  • User → edge: 30–80ms.
  • Edge → home region: 0 (local) or 100–200ms (cross-region routing miss).
  • Home region: app + DB: 30–100ms.
  • Total: 60–380ms.

Cross-region routing failures (a tenant served from the wrong region) kill UX. Test thoroughly.

Cost

Multi-region is more expensive:

  • 3× compute (one per region, lower utilization in each).
  • Cross-region traffic charges.
  • More ops (3× the dashboards to watch).
  • Per-region certificates, secrets, monitoring.

Plan: 2–3× single-region cost for the same workload. Charge enterprise pricing.

Common mistakes

1. Active-active without consensus

Two writers updating the same row in two regions = silent corruption. If you go active-active, use distributed SQL.

2. No tenant pinning awareness in code

Code assumes “the database” is one. After multi-region, code accidentally writes to the wrong region. Audit.

3. Forgetting backups per region

EU data backed up in US violates residency. Per-region backup pipelines.

4. Cross-region synchronous writes

A 300ms RTT for every write × 1000 writes per page load = unusable. Async replicate; serve writes locally.

5. No failover practice

Untested failover fails. Schedule game days. See Chaos Engineering .

What I’d ship today

For a SaaS going multi-region:

  1. Tenant pinning as the model.
  2. 3 regions (US, EU, APAC if APAC matters).
  3. Per-region Postgres + ElastiCache + S3.
  4. Cross-region async replicas for DR.
  5. Global edge router (Cloudflare Workers) for routing.
  6. Region-aware deploys via ApplicationSet.
  7. Quarterly DR drills.

Read this next

If you want a multi-region SaaS reference architecture, it’s at rajpoot.dev .

Building something AI-, backend-, or data-heavy and want a second pair of eyes? I do consulting and freelance work — see my projects and ways to reach me at rajpoot.dev .