TL;DR
An active-active architecture distributes edge functions across multiple PoPs, instead of maintaining a site as a passive backup. This makes failover and maintenance part of ongoing operational processes. For internal platform services, this means the public access, protection functions, and routing must be resilient themselves—regardless of where the backends are operated.
Introduction
High availability does not end at the cluster or data center edge. A platform service can have multiple backends and still fail if its central entry point relies on a single location, load balancer, or DNS system. This is where a frequently overlooked single point of failure arises: the upstream edge layer.
The architectural decision between active-passive and active-active affects not only compute resources. It also determines how traffic is received, distributed, protected, and rerouted in case of disruptions. A distributed multi-PoP architecture with actively operated sites treats the edge as a shared platform component—not as a passive emergency site that only becomes relevant in a crisis.
1. Active-Active Begins Before the Backend
In active-passive models, a primary site typically handles the traffic. A secondary site holds resources but only takes over after a disruption. This model can work if the switchover process is reliable, fast, and regularly tested. However, it creates an additional operational dependency: the passive path must be correctly activated, reachable, and sufficiently sized in case of failure.
Active-active, on the other hand, distributes processing across multiple simultaneously used PoPs. Each site is part of regular operations. If a PoP or part of its path fails, traffic can be processed through other active sites. This reduces dependency on a single switchover event.
For platform services, this distinction is relevant because the edge entry often bundles multiple functions: Anycast L4 and L7 load balancing, TLS termination, WAF, DDoS protection, and routing to the backend. If these functions are concentrated at a single location, the platform remains vulnerable to outages despite redundant backends.
2. Multi-PoP Changes the Failover Model
Failover is not just about where traffic is directed after a failure. What matters is who detects the failure, at what level it is detected, and how the remaining path is evaluated. A DNS failover can cover different failure scenarios than Anycast-based routing or a backend health check.
In a multi-PoP active-active architecture, these levels work together. The edge receives traffic in a distributed manner, checks the reachability of backends, and can remove faulty targets from distribution. This allows differentiation between a PoP failure, a network path failure, and an actual platform service failure.
This also changes operational processes. Failover is not a rare emergency procedure but part of normal operations. Maintenance work, routing changes, and backend switches must be planned so that active paths can be controlled and modified. Regular tests are still necessary, but they test not just an unused backup path but the behavior of a continuously distributed system.
3. The Edge Remains Separate from Compute
Active-active at the edge does not automatically mean that backends are also operated in an active-active manner. A service can still run behind the edge in a single cluster, region, or with another provider. In this case, the edge increases the resilience of public access but does not eliminate backend failures.
This separation is architecturally important. Edge functions handle public traffic entry, protection, termination, and load distribution. The compute infrastructure runs applications and platform components. For a robust failover model, both levels must be considered separately: What happens in case of a PoP failure? What if a cluster is unreachable? And what states should a backend health check consider as functional?
The ayedo Edge Cloud is designed for this separation as a distributed multi-PoP platform. Its own autonomous system and network infrastructure provide the framework for edge operations. Backends can be operated in ayedo Managed Kubernetes, in own clusters, or with other providers. This keeps the edge architecture decoupled from the chosen compute location.
4. High Availability Creates Operational Obligations
An active-active architecture reduces individual failure risks but does not automatically make operations easier. Multiple active paths mean more states that need to be monitored and evaluated. Routing, health checks, TLS configurations, WAF rules, and backend assignments must be consistently maintained.
Defining "healthy" is particularly critical. An accessible port does not prove that a platform service is usable. Health checks must match the respective service semantics and should not lead to unstable switching due to short-term errors. At the same time, a truly faulty backend must be quickly removed from traffic.
For companies, this results in organizational consequences: network, platform, and application teams must define common failure scenarios. Runbooks should cover not only the failure of a cluster but also PoP, DNS, and routing scenarios. The active-active architecture is thus less a single feature than an operational model that connects technical responsibilities and tests across multiple levels.
Practical and Operational Scenario
A company operates an internal developer platform with API access, user interface, and automation services. The workloads run in two Kubernetes clusters with different providers. In an active-passive model, a central site handles all edge traffic; the backup path is only activated in case of a major failure.
In an active-active architecture, traffic is received across multiple edge PoPs. A backend health check detects that a cluster no longer reliably provides the platform service and removes this target from distribution. If an edge PoP also fails, access remains available through other active PoPs. The application does not need to be operated at the same location as the edge. Failover is distributed across multiple levels instead of relying on a single switchover.
FAQ
Is Active-Active the Same as Two Active Kubernetes Clusters?
No. Active-active can initially concern the edge. Whether multiple backends are used productively at the same time depends on the application, data model, and operational strategy.
Does Anycast Replace Every Failover Mechanism?
No. Anycast distributes access but does not replace backend health checks or application-specific error detection and appropriate routing rules.
When Is Active-Passive Sufficient?
Active-passive can be sufficient if switchover, capacity, and data consistency are managed and regularly tested. The edge remains a separate failure domain.
Conclusion
High availability is incomplete if only the compute level is redundantly designed. A single edge location can become a common point of failure despite multiple clusters. The active-active and multi-PoP architecture of the ayedo Edge Cloud classifies public access, protection, and failover as an independent platform layer. It remains crucial to plan edge and compute separately and consciously connect their failure and operational models.