Active-Active and Backend Failover in Conjunction

TL;DR

Active-Active at the edge does not eliminate backend failure. High availability is achieved only when both layers are planned separately and technically linked: The edge redundantly distributes incoming traffic, while backend health checks assess the reachability of individual targets. Only then does a reliable backend failover emerge.

Introduction

A redundant access point is not a highly available application. If a backend fails, even an active-active edge can continue to reliably distribute traffic to a non-functional target. Conversely, a redundant compute cluster is of little help if the public entry, routing, or load balancing itself forms a central fault domain. Therefore, high availability must be considered along the entire requirement chain: from the Anycast entry through edge processing to the backends. The key is the clear separation of edge and compute. The edge cloud handles the reception, protection, routing, and distribution of traffic. The compute infrastructure operates the application. Backend failover connects both areas of responsibility without mixing them.

1. Active-Active at the Edge Reduces the Fault Domain

In an active-active architecture, multiple edge locations can simultaneously process incoming traffic. Anycast ensures that an IP address is reachable from various network positions and that traffic can be absorbed by the available edge infrastructure. If a single edge path or instance fails, the entire public entry does not need to be switched.

This is architecturally different from a single load balancer with a standby system. There often exists a central switching point whose state, routing, and reachability are themselves critical. A distributed active-active edge with its own network infrastructure and autonomous system reduces this dependency at the access level.

However, this only addresses one fault domain. The edge can continue to accept requests, terminate TLS at the edge, apply web application firewall rules, and distribute traffic. Whether a backend can still process the request meaningfully is a separate question. Active-active thus initially describes the operational readiness of the edge, not automatically the redundancy of the application.

2. Backend Failover Needs Reliable Health Checks

Backend failover is based on a state decision: A target is used as long as it meets the defined reachability and functionality criteria. Backend health checks provide the technical foundation for this. They not only check if a port is reachable but should ideally reflect a state meaningful for the service. A process can accept connections even though dependent databases, queues, or internal services are already unavailable.

The quality of the failover therefore depends on several parameters: check interval, timeout, number of necessary failed attempts, and time until a backend is resumed. Too aggressive values can trigger unnecessary switches during short disruptions. Too conservative values, on the other hand, keep traffic at a defective target for too long. Both create operational risks: unstable load distribution in the first case, prolonged error times in the second.

Health checks are also no substitute for application design. They detect availability from the edge’s perspective but not automatically business correctness, data consistency, or safe repeatability. For mutating requests, idempotency, session behavior, and possible side effects must be evaluated separately.

3. Edge and Compute Must Be Planned as Separate Layers

The edge cloud is the public entry point before applications and APIs. It protects and processes incoming traffic, takes over load distribution, and can remove backends from the public network through backend cloaking. The compute infrastructure, on the other hand, executes the workloads and decides on replication, data storage, cluster operation, and restart. This separation prevents the availability of a single compute provider from being automatically equated with the availability of the public entry.

For the architecture, this means: Backends can be operated on ayedo Managed Kubernetes , in their own Kubernetes clusters, or with other providers. The edge functions remain an independent layer. A switch or failover to another backend does not have to change the public DNS name or the external IP structure of the application.

This decoupling also facilitates organizational decisions. A platform team can centrally operate the edge and standardize policies, certificates, protection mechanisms, and statistics, while application teams independently manage their compute environment. A prerequisite is a clear responsibility for which signals trigger a failover and who evaluates their impact.

4. Redundancy Needs Coordinated Operational Logic

An active-active edge entry and multiple backends do not automatically result in an active-active application. Backends can be productive in parallel, operated as primary and secondary systems, or only available for a defined restart case. The edge can consider available targets based on health checks, but it cannot compensate for missing data replication or contradictory states between application systems.

This is particularly relevant for sessions, write accesses, and regionally distributed data. If requests are directed to another backend after a failure, it must know the required state, or the application must work statelessly. Otherwise, correct technical failover leads to business errors. Connection draining and controlled resumption are also important to ensure that ongoing connections are not unnecessarily terminated and a restored backend is not immediately overloaded.

Operationally, edge metrics and backend signals should be evaluated together. Traffic and usage statistics show how distribution changes; health checks explain why targets were removed from or added back to the pool. Only this combination makes failover understandable and testable.

Practical Scenario: Two Backends, One Common Edge Entry

An API runs in two separate Kubernetes environments. Both are accessible via the ayedo edge cloud; the public entry remains independent of a single compute location through Anycast and the distributed edge structure. Backend health checks examine an application-related endpoint. As long as both targets are healthy, the edge distributes the traffic according to the configured load distribution.

If a backend’s dependent database fails, the container process may still be reachable. A simple TCP check would continue to consider the target. An appropriate health check, however, recognizes the non-functional service and removes the backend from distribution. The traffic goes to the remaining target. For non-idempotent requests, repetitions and already started transactions must still be handled at the application level.

FAQ

Is Active-Active at the Edge the Same as Active-Active in the Backend?

No. Active-Active at the edge describes the parallel processing of public traffic. Backend activity, data replication, and business consistency must be implemented in the compute and application layer.

When Is a TCP Health Check Sufficient?

For simple reachability checks, TCP may suffice. For APIs and applications, the check should ideally examine a service state that also considers critical dependencies.

Does Backend Failover Prevent Data Loss?

No. Failover distributes traffic to an available target. Data durability, replication, transaction security, and repeatability remain tasks of the application and its compute infrastructure.

Conclusion

Multilayered high availability does not arise from a single redundant component. The edge must provide the public entry actively-active and provider-independent, while backends ensure their own availability and data consistency. Backend health checks form the link between both layers but do not replace robust application design. In this model, the ayedo edge cloud is an independent edge platform in front of different compute environments—not merely a load balancer in front of a single cluster.