TL;DR
Routing-based failover decides at the edge which accessible backend pool receives a request or connection. Unlike DNS failover, the client does not need to resolve a new target name first. This shortens the response path, makes health statuses immediately usable, and separates public access from the actual compute infrastructure.
Introduction
A DNS entry cannot reliably reflect whether a specific backend pool is currently processing requests. DNS distributes names and addresses, while the actual availability decision becomes visible only during connection establishment and request processing. If failover is implemented solely via DNS, response time and effectiveness additionally depend on TTLs, resolvers, caches, and existing connections. Routing-based failover therefore intervenes at a different point: The edge receives the traffic, checks the reachability of configured backends, and directly selects the available pool for forwarding. This is particularly relevant for APIs and web applications with multiple operational locations or providers.
1. The Failover Decision Belongs at the Traffic Entry
In routing-based failover, the central decision lies between the client and the backend. The request first reaches a public edge endpoint. There, based on the protocol, the service, and the state of the backend pools, it is determined where the traffic will be forwarded. If the primary pool fails or is unreachable, the edge can route to an alternative pool.
At Layer 4, this decision occurs at the level of connections and transport data. This is suitable for TCP-based services where the edge does not need to evaluate the application content. Layer 7 can additionally process HTTP or HTTPS traffic and distribute the respective web or API service at the application level. The key point in both cases is: The client remains at the public endpoint, while the internal target can change.
2. Backend Health Checks Provide the Basis for Decision-Making
Failover is only reliable if the edge systematically evaluates the state of the backends. Health checks verify whether a backend or a backend pool is reachable and suitable for forwarding. It is important to distinguish between network reachability and actual service availability: An open TCP connection does not automatically mean that an API provides correct responses.
The routing decision must also align with the pool model. A pool can contain multiple backends, while another pool serves as a fallback target. If the primary pool is deemed unavailable, the edge routes new connections or requests to the alternative pool. For operations, it is important to make state changes traceable. Traffic and usage statistics help recognize the impact of a failover and distinguish between backend problems, routing events, and normal load distribution.
3. Direct Edge Decision versus DNS Failover
DNS failover changes the response to a name resolution. Resolvers and clients then receive a different address or target. This approach can work but is tied to the DNS resolution path. TTLs are not always strictly adhered to, resolvers can cache responses, and existing connections do not automatically switch targets. Moreover, DNS primarily distributes addresses; the actual backend health must be integrated into the DNS logic.
Routing-based failover, on the other hand, decides when traffic enters at the edge. Name resolution still points to the public service, while the edge selects the reachable backend pool. This keeps the public address stable, and the failover path is not extended by additional DNS caches. DNS remains relevant for Anycast DNS and multi-provider DNS but does not replace the downstream routing decision for specific applications.
4. Failover Also Changes the Operational Architecture
An alternative backend pool is not just a technical switch. Applications must consider states, sessions, data storage, and dependencies across both targets. A stateless API service is usually easier to redirect than an application whose sessions or write accesses are tied to a single location. Routing can shift the traffic but cannot correct inconsistent data sets.
The edge cloud separates public access from the compute infrastructure. Backends can be operated with ayedo Managed Kubernetes, in own Kubernetes clusters, or with other providers. Backend cloaking prevents internal target structures from becoming part of the public address space. A distributed multi-PoP architecture with an active-active principle also reduces dependence on a single edge location. Failover is thus treated as an interplay of reachability, routing, and application design—not as an isolated DNS configuration.
Practical and Operational Scenario
An API runs in parallel in two Kubernetes clusters with different providers. Both clusters are accessible via a common public service; one pool is primary, the other serves as a fallback target. The edge checks the backends and initially routes new API requests to the reachable primary pool. If its API service fails, the alternative pool takes over without clients needing to resolve a new DNS entry.
In a DNS-based approach, a different address would first need to be published. Caches and existing connections can lead to a portion of the traffic still reaching the failed target. With edge routing, the public endpoint remains unchanged. However, the application must be designed for parallel states, data access, and possible request repetitions.
FAQ
Does routing-based failover completely replace DNS?
No. DNS remains relevant for name resolution and for Anycast and multi-provider scenarios. Routing-based failover takes over the decision of which backend pool processes the already incoming traffic.
Does failover apply equally to Layer 4 and Layer 7?
The basic principle applies to both levels. Layer 4 is connection-oriented, while Layer 7 processes HTTP or HTTPS traffic and can handle application services more distinctly.
What happens to existing connections?
Failover primarily affects new connections or requests. Existing sessions may remain with the failed backend or fail and must be handled by the protocol and application.
Conclusion
Routing-based failover shifts the availability decision to where the traffic is actually processed. This shortens the response path compared to a pure DNS redirection and keeps the public endpoint stable. For APIs and web applications, it is crucial to jointly plan health checks, backend pools, and application states. The ayedo Edge Cloud forms the upstream routing and protection layer—regardless of where the actual Kubernetes or compute workloads are operated.