Cleanly Separating BGP Routing and Backend Failover

TL;DR

BGP routing determines which network path a client uses to reach the edge. However, it does not indicate whether a specific backend is operational. This task is handled by health checks and backend failover within the edge cloud. Separating these two failure domains prevents false expectations and simplifies operational analysis.

A common misconception in distributed architectures is that if an application is unreachable, the routing must have failed. In reality, errors often lie beyond the edge, such as a failed backend, a faulty service, or a disrupted cluster connection. Conversely, a properly functioning backend can be useless if the path to the edge is not working.

Thus, BGP routing and backend failover address different issues. BGP determines the reachability of an IP prefix over the network. The edge cloud then decides whether and to which backend a request is forwarded. This distinction is essential for architecture, monitoring, and incident response.

1. BGP Determines the Path to the Edge

BGP, the Border Gateway Protocol, distributes routing information between autonomous systems. When an IP address or prefix is announced via BGP, the internet can calculate a path to this destination. This concerns the reachability of the network address—not the state of the application behind it.

In an Anycast architecture, the same prefix can be announced at multiple edge locations. Routing typically leads a client to an edge instance deemed suitable from a network perspective. The specific selection depends on BGP decisions and the view of the respective network. BGP does not know the HTTP status of a backend or the readiness of a Kubernetes service .

This is a clear failure domain: if an edge announcement or network path fails, it affects the reachability of the edge. A healthy backend cannot help in this case because the traffic does not reach the edge. At ayedo, the edge cloud’s own autonomous system and network infrastructure form the basis for this external reachability.

2. Health Checks Assess Backend Reachability

Once a request reaches the edge, a different responsibility begins. Health checks verify whether a backend is reachable from the edge’s perspective and suitable for traffic. Depending on the configuration, this may involve checking a network service or an HTTP/HTTPS endpoint. The key point is: the check assesses the state of the target behind the edge, not the BGP path of the client.

A successful BGP routing therefore only means that traffic can reach the edge. It does not guarantee that the selected upstream will respond, that a service is working correctly, or that an application is functionally operational. Conversely, a backend can be healthy even if individual external routing paths to the edge are disrupted.

Health checks provide a technical foundation for automated decisions. They inform the edge about which backends are available for traffic distribution. For operations, checks must be realistically configured: an accessible port proves less than a meaningful application endpoint, while overly deep checks can create unnecessary dependencies.

3. Backend Failover Is Not a BGP Decision

Backend failover describes the edge’s response to an unavailable or unhealthy backend. Instead of sending further requests to this target, the edge can switch to another available backend. This can be relevant within a cluster, between environments, or across provider boundaries—depending on the chosen architecture.

This decision is made by the edge cloud based on its backend and health check configuration. BGP is not involved. Changing the backend selection does not necessarily require a new route or a change in public IP reachability. This is the operational advantage: the public entry point can remain stable while the internal target selection changes.

The separation also reduces the scope of errors. A faulty backend does not automatically trigger a global routing change. This avoids unnecessary convergence times and keeps external network adjustments away from application-level recovery mechanisms. However, backend failover does not replace good deployment or cluster design. It only distributes traffic to targets that are actually recognized as available.

4. Two Failure Domains, Separate Operational Indicators

For troubleshooting, routing and backend signals must be evaluated separately. A BGP or edge reachability problem is indicated, for example, by requests not reaching certain edge accesses. A backend problem, on the other hand, often only becomes apparent after traffic is successfully accepted: health checks fail, connections to the upstream are rejected, or responses are missing.

This distinction also affects alerting and responsibilities. Network and edge personnel analyze prefix announcements, paths, and edge reachability. Platform or application teams investigate backend states, services, pods, and dependencies. Joint dashboards should therefore make traffic distribution, health check results, and backend failover visible without forming a single availability indicator.

Architecturally, the ayedo edge cloud allows the public entry to be operated independently of the compute infrastructure. It can accept traffic via Anycast, check backends, and redistribute if necessary—even with Kubernetes clusters operated by ayedo or other providers. The edge thus remains responsible for entry and forwarding, while the compute environment executes the workloads.

Scenario: Different Reactions to the Same Outage

Suppose a company operates a Kubernetes service in two environments. Both backends are accessible through a stable public edge entry. If a service in environment A fails, the health checks for this backend fail. The edge removes environment A from the traffic distribution and redirects requests to environment B. BGP remains unchanged.

Conversely, if the reachability of an edge announcement or a network path fails, the traffic cannot reliably reach the responsible edge. In this case, backend failover within the edge does not help. An alternative backend only becomes relevant when an edge can accept the request and perform the backend selection. The measures thus lie in different operational processes.

FAQ

Can Backend Failover Compensate for a BGP Disruption?

No. Backend failover only takes effect once an edge has accepted the traffic. If the path to the edge is disrupted, the cause must be investigated in the routing, edge reachability, or upstream network.

Does Every Backend Failover Require a Routing Change?

No. The edge can change the target selection based on health checks and backend configurations while the public entry point remains unchanged.

What Should an Alert Distinguish First?

Whether requests reach the edge and whether the edge finds healthy backends. These two signals separate routing issues from backend and application issues.

Conclusion

BGP routing and backend failover belong to different layers. BGP decides the path to the edge; health checks and backend failover decide on the use of available targets behind the edge. This architectural clarification improves monitoring, responsibilities, and incident response. A platform like the ayedo edge cloud connects both layers in operation but does not replace them with the same mechanism: network reachability and backend availability remain separate failure domains.