Why it matters
Running code or copying a table in two regions does not make a product fail over. Customers need a working front door, identity, data, and background processing in the surviving region. Each dependency needs a deliberate recovery path.
A healthy replica can still be behind on data or unable to perform a write. Routing by latency alone can also send a tenant to a region that may not process its data. Define the eligible region and write owner before switching customer traffic.
Decisions to make
- Decide whether each tenant has a home region, a standby region, or active service in several regions.
- Define what a health check must prove before a region receives customer traffic.
- Choose which region may write each record and how a previous writer is fenced during promotion.
- Set an acceptable replication lag and tell customers which recent changes could be missing.
- Map dependencies beyond the database: sign-in, files, queues, webhooks, secrets, and support tools.
- Decide how traffic returns after recovery without replaying work or violating residency rules.
Build checklist
- List every customer-facing request and the regional resources it needs to succeed.
- Route a stable hostname only to regions that are ready for that tenant and operation.
- Make write ownership explicit and reject writes from a region that has lost authority.
- Track replication lag and pause promotion when required data or keys are unavailable.
- Fence duplicate schedulers, stream consumers, and outbound deliveries during a switch.
- Drill failover and failback with real sign-in, reads, writes, and asynchronous work.
Common mistakes
- Treating replicated tables as a complete failover plan for the application.
- Sending every customer to the nearest region without checking tenant home or residency.
- Allowing old and new regions to run the same billing or delivery worker at once.
Tools & references
3 starting points to compare or study. Check fit, maintenance, terms and current capabilities before choosing one.