TL;DR:
Failover is not a single switch function but a chain of detection, decision, forwarding, and stabilization. Edge routing typically reacts closer to the ongoing traffic, while DNS failover is delayed by TTLs, resolver, and client caches. Existing connections follow different rules than new requests.
Failover is often described as a state change: A backend fails, and an alternative backend takes over. Technically, however, several interdependent steps lie in between. A health check must detect the failure, a routing instance must evaluate the information, new connections must receive a different path, and the traffic must stabilize. If DNS is changed instead, TTLs, resolver caches, and local client caches are added.
The crucial difference is therefore not only in the detection time. The switch path, visibility for existing connections, and the point in the architecture where the decision is made are also relevant. Failover response paths should therefore be analyzed as a process—not as a switch with a blanket switch time.
1. Backend Health Checks Determine the First Reaction Point
Every failover begins with an observation. A backend health check, for example, checks whether a service is reachable and delivers an expected response. It is important to distinguish between network reachability and application state: A reachable server may still not be able to process functional requests.
A reliable state change only emerges from multiple check results. Too aggressive checks can interpret short-term network or load issues as failures. Too conservative checks, on the other hand, prolong the time traffic is directed to a non-functional target. Check interval, timeout, and the required number of consecutive errors directly influence the reaction characteristics.
In an edge platform, such health checks are evaluated before forwarding to the backend. The edge can then remove a target from active routing or use an alternative path. However, the health check is not yet a failover: It only provides the information on which the routing decision is based.
2. Edge Routing Specifically Switches New Forwarding
In edge failover, the public entry point remains unchanged. The edge continues to receive traffic over the existing address and decides based on the current backend state where new connections or requests are forwarded. This eliminates the dependency on a renewed DNS resolution for each switch operation.
The reaction path is simplified: A health check detects an error, the edge updates the available backend pool, and then new forwarding is directed to an alternative target. At Layer 7, the decision can be made at the request level; at Layer 4, the connection's lifespan is more influenced by TCP or UDP states. An already established TCP channel is not automatically moved to another endpoint.
The ayedo Edge Cloud combines such backend health checks with edge routing in a distributed multi-PoP and active-active architecture. This is particularly relevant when the public entry point should remain stable while backends are operated in different environments—such as in self-hosted or provider-hosted Kubernetes clusters. The edge remains responsible for entry, protection, and forwarding; the compute infrastructure remains the place of application.
3. DNS Failover Shifts the Decision to Resolvers and Clients
In DNS failover, it is not primarily the forwarding at the edge that changes, but the response to a name resolution. A health check can determine that a target is unavailable, after which DNS provides an alternative address. However, the further traffic only reaches this target when a new DNS resolution occurs.
The configured TTL limits the validity of a response but does not guarantee an exact switch time. Recursive resolvers, operating systems, applications, and local network components can cache responses for different lengths of time or apply their own reuse logics. This creates a distributed transition phase between the state change and the actual use of the new target.
DNS failover is useful when the public entry itself should switch between independent endpoints or when a change is required outside a single edge routing domain. Anycast DNS and multi-provider DNS can make the DNS layer more resilient but do not eliminate the effect of caches. In the ayedo Edge Cloud, DNS is therefore a separate response path alongside edge routing, not its replacement.
4. Existing Connections Make the Difference Visible
Failover affects new and existing connections differently. A new connection can reach a healthy backend after the routing decision. An already established connection, however, initially remains bound to its previous network path. If the backend fails, the client, a proxy, or the application must terminate the connection, rebuild it, or retry a request.
With HTTP over an edge, the public address can remain stable for the client while the internal forwarding changes. This simplifies the recovery of new requests but does not replace transaction logic. Repeats are only safe if the application can handle them, for example, through idempotency or suitable request IDs. With long-running WebSockets, streaming connections, or stateful sessions, the interruption is much more visible.
In DNS failover, an existing connection also remains on its original target. Additionally, new connections can still use the old address as long as the DNS response is cached. Stabilization therefore consists not only of switching but also of retry behavior, session handling, connection draining, and monitoring error rates after the decision.
Scenario: Edge Switching or DNS Change?
Suppose an API cluster is unavailable while a second cluster remains operational. In edge failover, the health check detects the error, removes the first backend from forwarding, and sends new requests to the second cluster. Clients retain the known public endpoint; however, existing connections must be rebuilt depending on the protocol.
In DNS failover, a new target address is published instead. Resolvers and clients adopt this information with a delay. During the transition phase, part of the new connections still reaches the failed target. The edge path thus reduces the impact of DNS caches, while the DNS path shifts the decision further outward. Which variant fits depends on the desired control point and the connection typology.
FAQ
Is Edge Failover Always Faster Than DNS Failover?
Not automatically. Key factors are health check parameters, routing updates, and protocol behavior. DNS failover is additionally dependent on TTLs and caches, which can cause the use of the new target to diverge more over time.
Are Existing TCP Connections Moved During Failover?
No. An existing connection is bound to its original path. If this fails, connection termination, rebuilding, or an application-side retry is required.
Does DNS Failover Need Additional Edge Routing?
Not fundamentally. DNS can switch between independent endpoints. However, edge routing is more suitable if the public entry should remain stable and the forwarding decision should be made centrally at the edge.
Conclusion
Failover should be modeled as a temporal process: detection by health checks, decision at edge or DNS, forwarding of new connections, and stabilization of ongoing communication. Edge routing reduces dependency on DNS caches, while DNS failover uses a broader but less immediately controllable switch path. The ayedo Edge Cloud integrates these mechanisms into a platform for public traffic entry, protection, and forwarding—regardless of where the backends are operated.