Single Region → Multi-Region Replication
Very HighExpanding from a single-region deployment to active-passive or active-active multi-region replication to reduce read latency for global users, increase availability during regional failures, and meet geographic data residency requirements : at the cost of replication lag, consistency complexity, and operational burden.
Topology Changes
From
Single-Region Deployment
To
Multi-Region Replication
Topology Mutations
Primary database replicates asynchronously to read replicas in secondary regions
Operational Impact
Replication lag of 10-500ms creates stale read windows; during network partition, replicas fall further behind
Anycast DNS or global load balancer routes users to nearest healthy region
Operational Impact
Failover latency when primary region fails: 30-120 seconds for DNS propagation
Application routes reads to local regional replica and writes to global primary
Operational Impact
Read-after-write consistency violations possible: a write to primary may not be visible on local replica for 50-500ms
Per-region Redis cache reduces cross-region read traffic to primary database
Operational Impact
Cache invalidation must propagate across regions: stale cache in secondary region after primary write
Secondary region reads are eventually consistent: replication lag determines staleness window
Operational Impact
User in secondary region who just wrote data may see old data on next read if read hits local replica
Migration Stages
Instrument all requests with user region. Measure existing cross-region latency. Establish replication lag alerting infrastructure. Document all write operations that require strong consistency: these cannot be served from secondary regions.
Provision database read replica in secondary region. Set up cross-region replication. Deploy application infrastructure in secondary region (compute, cache, networking). Validate replication lag at production write rates.
Route secondary-region users' read requests to local replica. Monitor replication lag, cache hit rates, and read-after-write consistency incidents. Start with non-sensitive reads (public content, product catalog) before user-specific reads.
Test regional failover procedures. Simulate primary region failure in staging. Validate DNS failover, replica promotion procedure, data consistency after promotion, and application behavior during failover window.
If active-active is required: implement conflict resolution strategy (last-write-wins, vector clocks, or CRDTs). Active-active dramatically increases consistency complexity : most teams should remain active-passive unless write latency is a proven requirement.
Migration Risks
Read-after-write violations are invisible to monitoring but visible to users: 'my change disappeared'
Mitigation
Track write LSN per user session; route reads to primary until replica confirms that LSN; accept primary load increase
Replica promotion during primary region failure requires manual intervention and causes data loss if replication lag is high
Mitigation
Document and test failover runbook quarterly; set maximum acceptable replication lag before automatic failover is blocked
Asynchronous replication means writes acknowledged by primary but not yet replicated are lost during primary failure
Mitigation
Use synchronous replication for critical writes (PostgreSQL synchronous_commit = remote_apply); accept write latency increase for durability guarantee
DNS-based failover has 30-120s propagation delay: users experience outage during propagation window
Mitigation
Use Anycast routing with health checks for sub-30s failover; implement client-side retry with exponential backoff
Coupling Changes
Regions are coupled by replication lag: primary region write rate directly affects secondary region read freshness
Consequence
Primary region write spike causes replication lag in all secondary regions simultaneously
Secondary regions can serve reads independently during primary region failure
Consequence
Reads remain available during primary region failure; writes require primary region availability
Cross-region operations require reasoning about replication lag and read routing
Consequence
Every feature must explicitly decide: eventual consistency from local replica, or strong consistency from primary
Consistency Model Changes
- ·Primary region writes remain strongly consistent (PostgreSQL synchronous_commit within region)
- ·Secondary region reads are eventually consistent: replication lag determines staleness window (typically 10-500ms)
- ·Active-active writes require a conflict resolution strategy: CRDTs, LWW, or operational transformation
- ·Cache invalidation across regions is eventually consistent: secondary region cache may serve stale data after primary write
Rollback Risks
- ·DNS changes for global routing require time to propagate: cannot instantly roll back secondary region traffic
- ·Once replica is promoted to primary during failover, the original primary cannot be demoted without data reconciliation
- ·Active-active write routing cannot be rolled back after data has diverged across regions