Multi-Region, Single Brain: Designing for Low Latency Across Geographies
Serving users globally without splitting the source of truth — CDN, read replicas, edge caching, and write-path routing.
Context
Our users spread across multiple regions. Those far from our primary data center experienced high latency — 200–400ms for API calls. We couldn't afford full multi-region active-active; we needed a simpler approach that brought latency down without duplicating our entire stack. The question was: what can we replicate at the edge, and what must stay centralized?
Constraints
- Single source of truth — we weren't ready for distributed writes and conflict resolution
- Budget — we couldn't spin up full replicas in every region
- Static and dynamic content mixed — some responses were cacheable; others had to be fresh
Architecture
We layered improvements: (1) CDN for static assets — images, JS, CSS — so they're served from the edge. (2) Read replicas for PostgreSQL in one secondary region — we route read queries from that region to the replica; writes still go to the primary. (3) Redis at the edge for cacheable API responses — tenant config, reference data — with short TTLs. (4) Write path always hits the primary region; we accept that writes have higher latency but reads are fast. We used geographic routing (or client-side region detection) to send users to the nearest read replica when possible. The key was identifying what was safe to replicate — reads, cached data — and what wasn't — writes, auth, anything that had to be strongly consistent.
Alternatives considered
- Full multi-region active-active: Conflict resolution, distributed transactions, and operational complexity we didn't need. Our write volume was low; read replicas were enough.
- Bigger instances in the primary region: Doesn't fix physics. A user in Asia hitting a US-East server will always have 150ms+ RTT. Replication is the answer.
Lessons learned
- Read replicas are the low-hanging fruit. Most traffic is reads; replicating reads gives you most of the benefit with minimal complexity.
- CDN for static assets is table stakes. We did that first; it was cheap and had immediate impact.
- Document what's replicated and what isn't. When debugging, you need to know whether you're looking at primary or replica data.