Failover at the Edge: Routing, States, and Limits

TL;DR

Edge failover is not a single switch decision. Anycast, routing convergence, backend health checks, and protocol states interlock in multiple steps. They address different classes of failures and have their own temporal limits. Mixing these layers overestimates the speed, scope, and automation of a failover.

An edge failover consists of multiple state changes: A backend can be removed from the pool while the Anycast network remains accessible. Conversely, a routing or PoP issue can affect public access even though the backends themselves are functioning properly. Only by considering these layers separately can we see which failures can actually be handled automatically.

1. Anycast and Routing Solve a Different Problem than Backend Failover

Anycast provides the same IP address across multiple network locations. The Anycast network distributes incoming traffic based on the current routing information. If an edge location or a relevant network path fails, the preferred route may change. Clients then send to another accessible entry point after routing convergence.

However, this is not a health check for the application. Routing does not automatically detect if a specific backend is producing HTTP errors, losing database connections, or unable to serve a single API path. These states are on a different layer.

The ayedo Edge Cloud uses its own autonomous system and network infrastructure in a distributed multi-PoP architecture. This provides the foundation for Anycast and an active-active model. However, it does not mean that every request is seamlessly redirected for every failure. Routing decisions and existing transport connections each have their own states.

2. Backend Health Checks Control the Traffic Pool

Backend health checks determine whether a target is still suitable for new connections or requests from the edge’s perspective. Depending on the protocol and configuration, different criteria may be relevant: reachability on Layer 4, successful application communication on Layer 7, or a defined health endpoint.

If the edge detects a faulty backend, it can remove it from distribution or initiate a failover to other backends. This is backend failover, not routing failover. The public Anycast address remains fundamentally the same; the selection within the edge platform changes.

The timing is crucial: A health check runs at intervals and may require several failed checks before a status change occurs. After recovery, a backend may not necessarily become immediately productive again. Thresholds, check intervals, and restart behavior are designed to avoid incorrect decisions but limit response speed. An overly aggressive check can trigger unnecessary failovers during short load spikes.

3. Failover Consists of States, Not a Switch

The statement “the system automatically switches on failure” is technically incomplete. First, a failure must be detected. Then, a new state is evaluated and distributed: for example, a backend marked as unhealthy, a changed routing path, or another accessible edge location. Only then can new traffic be handled accordingly.

New and existing connections differ. An already established TCP connection cannot be arbitrarily moved to another backend because its connection state depends on the previous path and destination. With HTTP, retries or new connections can use an alternative path; however, this depends on the client, protocol, and application. Not every request can be safely retried.

TLS sessions, long-lived connections, WebSockets, and stateful applications also set limits on failover. TLS termination at the edge can simplify the transition but does not replace a state strategy in the backend. Failover shifts traffic—it does not replicate application sessions or correct inconsistent data.

4. Scope and Automation Level Must Be Specifically Assessed

An automatic failover can only address the class of failure for which a mechanism can capture states and determine an alternative route or target. A failed service endpoint is a different situation than a complete provider outage, a routing error, or an overload of all available backends.

The scope is also limited. Backend health checks can remove a target from the traffic pool, but they do not prove that an entire application is functioning correctly. Anycast can enable access via a different network route, but it does not guarantee that a healthy application is available there. Routing convergence, in turn, takes time, and resolvers, clients, or existing sessions may continue to use old states.

Therefore, failover should be modeled as a process with observable transitions: detection, evaluation, control, and stabilization. This includes health and traffic statistics, defined responsibilities, and tests for partial and complete failures. Economically, this precision determines whether a failure is contained or merely passed between multiple components.

Scenario: Backend Failure Without Edge Failure

An API runs actively on two Kubernetes clusters operated by different providers. Both clusters are accessible via the ayedo Edge Cloud. One cluster loses its database connection; however, the nodes and network remain reachable. A passive TCP check might not detect the error. A suitable Layer-7 health check can determine that the service is no longer functionally available and remove the backend from distribution.

The Anycast address remains unchanged. The remaining backend takes over for new requests. Existing connections may still fail, and requests with non-idempotent write operations should not be blindly retried. Conversely, if an edge PoP or routing path fails, error handling occurs at the Anycast and routing level—regardless of whether both backends are healthy.

FAQ

Is Anycast Alone a Failover Mechanism?

No. Anycast distributes reachability over routing paths. It does not replace backend health checks or the verification of whether an application is functionally correct.

How Fast Is Edge Failover?

It depends on detection intervals, thresholds, routing convergence, connection states, and client behavior. A general switch-over time cannot be technically specified reliably.

Does Failover Work with Stateful Applications?

Only to a limited extent. The edge can redirect traffic, but sessions, transactions, and data consistency must be secured by the application and its backend architecture.

Conclusion

Edge failover is a chain of state evaluation and traffic control, not a single switch. Anycast and routing address reachability at the network level; health checks control the selection of healthy backends. The ayedo Edge Cloud connects these layers in a provider-independent edge platform without removing the limits of sessions, routing convergence, or application states. Robust failover architectures therefore plan not only for the switch but also for detection, return, and functional consistency.