Active-Active Architecture for Highly Available Backends

TL;DR

High availability is not achieved solely through redundant backends. The entry layer must also withstand failures of individual locations, network paths, or components. A distributed active-active architecture combines multiple active edge instances with backend health checks and controlled failover. The key is to consider edge and compute together.

Introduction

A redundant backend is not highly available if all public traffic flows through a single active entry layer. If this central entry point fails, healthy applications become unreachable. Conversely, a distributed edge architecture is ineffective if it continues to route traffic to unreachable or faulty backends. High availability is thus a chain of at least two levels: the distributed acceptance and processing of traffic and the controlled accessibility of downstream workloads. An active-active architecture must integrate both levels and continuously evaluate states.

1. Active-Active Begins at the Public Entry

In an active-active architecture, multiple edge instances are simultaneously active. Traffic is not switched to a passive reserve only after the failure of a primary instance but is fundamentally distributed across multiple active components or locations. This eliminates a single active entry point as a critical dependency.

For the edge cloud, this means a distributed multi-PoP architecture with its own network infrastructure and autonomous system. Anycast can represent public access across multiple reachable edge locations. The specific traffic path then depends on routing, accessibility, and the available edge functions.

The operational advantage lies not only in fault tolerance. Maintenance work, disruptions at individual locations, or impairments of specific network paths do not necessarily interrupt the entire service. However, it is essential that the active edge components logically represent the same service and do not each form an isolated state. Otherwise, despite distributed infrastructure, a hidden single point of failure emerges.

2. Edge Availability and Backend State Are Separate Levels

The accessibility of the edge says nothing about whether the application behind it is functional. An Anycast endpoint can still accept requests while a backend fails to respond due to a failure, overload, or network issue. Therefore, edge availability and backend availability must be measured separately and then combined.

Backend health checks verify if defined downstream targets are reachable and suitable for traffic. The choice of checkpoint is relevant: a network check may only confirm the reachability of a port, while an HTTP or HTTPS check can additionally verify a usable response from the service. The appropriate depth of checks depends on the protocol and error pattern.

In case of failure, the edge must not blindly distribute to an unhealthy target. Failover must be linked to a defined state: such as the absence of successful health checks or the loss of a backend group. This turns mere redundancy into a viable high availability logic. The edge cloud connects load balancing, health checks, and failover without replacing the compute infrastructure itself.

3. Failover Needs Clear States and Controlled Decisions

Failover is not synonymous with “just switch on errors.” A robust architecture must define when a backend is considered unavailable, how long this state is observed, and which alternative target is used. Too aggressive switching can trigger unnecessary changes during brief network disruptions. Conversely, sluggish decisions prolong the time users reach faulty backends.

It is particularly important to distinguish between a single faulty backend and a larger failure. If only one instance fails, traffic should ideally be distributed to healthy targets within the same group. If an entire backend zone or cluster is unreachable, failover to another available backend group is necessary. The architecture must ensure that the alternative target indeed has capacity and the required data or states.

Protocol and application also influence the decision. For stateless APIs, a switch is usually easier than for long-running connections or sessions with local state. Health checks and failover do not automatically resolve every application characteristic. They provide the technical foundation; session handling, replication, and data consistency remain tasks of the backend and compute architecture.

4. Shared Operational Responsibility Must Not Be Invisible

A distributed edge reduces the risk of failure at the public entry but does not completely shift operational focus away from the teams. Responsibilities must be clearly separated between edge and compute. The edge cloud handles acceptance, routing, protection, and distribution of traffic. The compute infrastructure is responsible for applications, workloads, data, and their internal redundancy.

This separation is also crucial for error analysis. A timeout can result from an unreachable edge path, faulty routing, a failed backend service, or cluster overload. Traffic and usage statistics, as well as the status of backend health checks, provide different perspectives. Only their combined evaluation reveals whether a problem lies at the entry or in the downstream service.

For companies, this has organizational and economic consequences: redundancy must be planned end-to-end. Multiple backend instances do not justify a high availability claim if DNS, edge, or network path remain centralized. Conversely, an active edge cannot compensate for a missing replication or failover mechanism in the backend.

Practical and Operational Scenario

A company operates an API in two Kubernetes clusters with different providers. Both clusters provide the same service but are not identically connected to public traffic. A distributed edge accepts requests via Anycast and uses health checks for both backend groups.

If an application pod group in Cluster A fails, the edge distributes traffic to remaining healthy targets. If the entire Cluster A becomes unreachable, failover switches to Cluster B. Conversely, if an edge location fails, the service remains accessible through other active edge locations. High availability thus arises from the interplay of a distributed entry layer, verified backend targets, and a truly usable second compute environment.

FAQ

Is an Active-Active Edge Automatically an Active-Active Backend?

No. Active-active on the edge describes the simultaneously operated entry layer. The backends must also be redundantly operated and integrated with appropriate routing and failover rules.

What Happens If All Backends Are Healthy, But an Edge Location Is Unreachable?

In a distributed active-active architecture, traffic can be processed through other active edge locations. This requires that routing and accessibility support the remaining path.

Are Backend Health Checks Sufficient for High Availability?

No. Health checks detect states and enable decisions. They do not replace redundant backends, replication, capacity planning, session handling, or a tested operational process.

Conclusion

High availability is an end-to-end property and not a feature of individual components. A distributed active-active architecture protects the public entry, while backend health checks and failover assess the accessibility of downstream services. The ayedo edge cloud integrates these levels into its own distributed network infrastructure and can also be operated with Kubernetes clusters outside of ayedo Managed Kubernetes. The coordinated architecture of edge and compute remains crucial.