Active-active
Active-active is a deployment topology in which multiple instances of a service, or multiple replicas of data, run simultaneously and all serve live traffic. It is a redundancy strategy and the counterpart to active-passive, where one instance handles traffic while one or more standby replicas remain idle until they are needed for failover.
In an active-active setup, every node is hot. Requests are spread across the nodes by load balancing, so capacity scales with the number of replicas, a form of horizontal scaling. When a node fails, the remaining nodes simply absorb its share of traffic. There is no promotion step and no interruption, which makes active-active attractive for systems that require high availability and fault tolerance.
The absence of a failover step is not free, though. Because the surviving nodes must carry the failed node’s load as well as their own, the cluster has to be provisioned with headroom: at least the capacity of one node, the so-called N+1 margin. Run the cluster at full utilization and the loss of a node pushes the rest past their limits, trading instant failover for saturation and latency spikes. Active-active therefore trades idle standby nodes for idle capacity on every node.
Active-active is commonly applied at two layers.
- Application layer. Multiple stateless service instances run behind a load balancer. Stateless design is what makes the topology viable here: because no instance holds exclusive state, any instance can handle any request. Where state must be kept, such as a shopping cart or a session, it is moved to an external store so that the instances stay interchangeable. Without that, the load balancer is forced into sticky routing or a shared session store, eroding the benefits.
- Data layer. Multiple database replicas accept writes concurrently, an arrangement also known as multi-leader replication. Each replica serves local reads and writes, and changes propagate to the others asynchronously.
The data layer is where the trade-offs bite. With several nodes accepting writes at once, concurrent updates can conflict, and replicas converge only through eventual consistency. Resolving conflicts requires strategies such as last-write-wins, version vectors, or application-level merge logic. Under a network partition the nodes can diverge into independent groups, a split-brain, and the coordination needed to keep them agreed is exactly the problem consensus algorithms exist to solve. That coordination sits at the heart of the CAP theorem trade-off between availability and consistency.
Active-active is most worthwhile in distributed software that cannot tolerate downtime during recovery, and in multi-region deployments where serving reads and writes from a node close to the user reduces latency. The cost is operational complexity. Every node must be kept in sync, the system must detect and route around unhealthy nodes, and the infrastructure runs at full capacity around the clock rather than keeping reserve nodes idle.