Geo-redundancy and DNS-based failover
In short: Geo-redundancy runs a service in more than one location so a site or region failure does not take it offline. DNS-based failover and global load balancing steer users to healthy sites, but speed depends on health checks and TTLs, and data replication between distant sites forces a consistency trade-off.
Why go beyond one site
Redundant servers in one data centre do not help if the building loses power, floods or is cut off. Geo-redundancy places copies of a service in separate locations: different availability zones within a cloud region, different regions, or your own primary and disaster recovery (DR) sites. Separation should be wide enough that one event, such as a regional power failure, does not hit both.
| Scope | Protects against | Typical latency between |
|---|---|---|
| Multiple racks | Rack power or switch failure | Negligible |
| Multiple availability zones | Single data centre loss | Low, a few milliseconds |
| Multiple regions | Regional disaster or provider outage in a region | Tens to hundreds of milliseconds |
See cloud regions and zones for how providers structure locations.
DNS-based failover
Global server load balancing (GSLB) and cloud DNS services monitor each site with health checks and return the address of a healthy site. If the primary fails, DNS starts answering with the backup address. This is simple and works for any protocol, but it has limits:
- TTL delays: resolvers cache answers for the record's time to live. A 300-second TTL means some users keep trying the dead site for up to five minutes. Use short TTLs, such as 30 to 60 seconds, for failover records.
- Ignored TTLs: some resolvers and applications cache longer than told.
- Health check quality: check a real application page, from several locations, so one probe glitch does not trigger failover.
Learn the basics in DNS explained.
Global traffic policies
Failover routing suits active-passive sites. Latency or geolocation routing suits active-active deployments, sending users to the nearest region. Weighted routing lets you shift traffic gradually, for example during a migration. Anycast is different: the same IP address is advertised by BGP from many sites and the network delivers packets to the nearest one. CDNs and public DNS resolvers rely on it, and failover happens at routing speed rather than waiting for TTLs.
The data problem
Moving traffic is the easy part. Each site needs current data. Synchronous replication across regions adds large write latency, so cross-region replication is usually asynchronous, which means a small RPO greater than zero (see CAP and PACELC). Active-active multi-region writes need conflict handling or a database designed for it.
- Decide whether the secondary is active, warm or cold, based on RTO and cost.
- Replicate data and configuration, including secrets, certificates and DNS records.
- Make sure the DR site has enough capacity and quota for full load.
- Keep dependencies regional: a DR site that still relies on the failed region's identity or logging service will not work.
- Run failover drills and record the real recovery time.
Tip: plan the failback too. Returning to the primary after an incident needs data resynchronisation and is often riskier than the failover.
Practice
A failover DNS record has a TTL of 3600 seconds. What is the problem?
How does anycast differ from DNS failover?
Why is cross-region replication usually asynchronous?
Key takeaways
- Geo-redundancy protects against site and regional failure.
- DNS failover is simple but limited by TTLs and health checks.
- Latency, geolocation and weighted policies steer active-active traffic.
- Anycast fails over at routing speed.
- Data replication and regional dependencies are the hard part; drill failover and failback.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.