DR Architecture Patterns
The reference architectures behind the tiers
Real DR architectures in the wild: cross-region DB replication (Aurora Global, Azure SQL geo, Spanner), RDS promote-and-cutover, frontend + CDN/DNS rerouting, data-plane state (uploads, queues) migration, and the 'do we really go active-active?' decision with conflict resolution.
What you will learn
- Map data-plane replication options per database family
- Design frontend + edge reroute patterns
- Decide on active-active vs active-passive honestly
Data is the DR crux: cross-region replicated DBs (Aurora Global Database, Azure SQL geo-replication, Cloud Spanner, AlloyDB CMEK, CosmosDB multi-region write, CockroachDB), or promote-a-read-replica for homegrown. Edge: CDN + DNS failover; uploads/queues get cross-region replication or replay.
What is this?
AWS: Aurora Global Database (storage-based replication, RPO often ~1s+..., failover ~1-2 min via secondary cluster promote), RDS cross-region read replica (promote → new primary, RPO=lag), Elastic Disaster Recovery (continuous block replication for VMs), S3 CRR (uploads), SQS→replay patterns, Route53 failover. Azure: SQL geo-replication (failover groups, RPO ≤ seconds), CosmosDB multi-region writes, Azure Site Recovery (VM replication), Storage GRS. GCP: Cloud Spanner (global, synchronous — multi-region), AlloyDB cross-region replica, Cloud SQL cross-region replica + promote, GCS dual-region/regional sync, Traffic Director / HTTP LB steering. Data-plane patterns: uploads to replicated buckets, queues via cross-region replay or event sourcing rebuild, cache rebuild after failover (cold cache hit = acceptable). Migration realism: promote in a window, version compat, idempotent replay. Conflict resolution for AA: LWW timestamp, per-shard sharding, unidirectional writes (user proximity), entities separated.
Why do you need it?
- The data tier is where DR is won or lost — replication choice sets your RPO.
- Cross-region DB replication exists as managed features now; picking the global-vs-promote model is the real design decision.
- Edge/DNS + CDN rerouting is the part that makes 'region-B' reachable in minutes.
- AAA's data conflict rules must be decided pre-failure or discovered in the worst fire.
Mental model
Two hotel reservations desks syncing via a fan-out ledger vs. one desk missing the whole building for the night
Cross-region replication
The second desk with sync replication (aurora-global-ish) instantly steps up when the first burns; a merely incremental 'replica' may lag just as the disaster peaks. Replication latency = your RPO ceiling.
How it works
- DB writes flow to primary; managed cross-region replication ships to the secondary region.
- Promote (or automatic failover) in the secondary; app connection/DNS points there.
- Edge/CDN objects already multi-region; DNS failover record reroutes the app entry.
- Uploads/queues replicate or replay into the surviving region.
- App starts cold-ISH (cache warm fails); acceptable per plan or warmed proactively.
Cross-region data + edge pattern.
Examples
Aurora Global failover dance
# Failover (AWS Aurora Global Database):# 1. rds-global-cluster failover --global-cluster-identifier <g># → secondary (region-B) promoted to primary# 2. App endpoint now points at region-B cluster writer# 3. RPO: storage-level replication (seconde-level), RTO ~1-2min# Instead-of: promote read replica (RPO = lag; RTO = promote time + DNS)Aurora Global gives near-continuous replication + fast promote + global read-scaling — the flagship cross-region DB pattern.
In production
- Aurora Global for the core checkout DB (RPO seconds, RTO ~2m).
- S3 CRR for uploads; user-facing content via CDN (any-region).
- Active-active for API workloads where regions need simultaneous writes + LWW conflict rules.
Best practices
- Treat RPO/RTO targets as the design constraints; pick replication that meets RPO instantly.
- Warm the edge: DNS records, certificates, and security groups in the standby region pre-created.
- Design uploads/queues to be replay/rebuild-safe (idempotency) across regions.
- Test the promote route — some 'managed failover' needs a manual API call; knife it into the drill.
- Decide AA vs AP on the conflict semantics (can two regions safely write the same logical records?).
Common mistakes
- Relying on async replication for RPO=0 promises (lag happens).
- Cross-region DB but app still pinned to old region's config/endpoint.
- Uploads stored only in the failing region; the DB recovered but attachments are gone.
- Thinking AA is 'more HA' without the write-conflict cost — two independent masters writing the same ID is the classic trap.
Debugging tips
- Promoted replica serves stale reads → measure replication lag; canary reads bump to primary temporarily.
- Failover to B but clients timeout → DNS TTL + LB/cert target mismatch; pre-stage aliases.
- Uploads in A vanished → CRR not enabled/buckets same-region; decide region-agnostic object topology.
- AA conflict surprise → audit id sets; pre-split sharding or add provenance fields to entities.
Interview checkpoint
Hands-on lab
- Set up primary + replicate (local postgres, logical/physical)
- Cut over the endpoint to the replica
- Observe RPO/lag reality
Promote a Cross-Region Replica (Simulated)
40 min · advanced
Quick quiz
The DB replication choice sets your:
AA's hidden cost is: