Active-active
Both sites serve users all the time. If one site is lost, the other is already carrying live traffic and simply takes the full load. For users, recovery is close to instant.
What happens in a disaster
This is what runs at each site on a normal day. Press Simulate a disaster to watch the primary site fail and the DR site take over, step by step.
How the pieces fit together
| Part | What it does |
|---|---|
| 1 Session replication | User sessions are kept in a shared, replicated store rather than on one server, so a user moved to the other site does not have to log in again. |
| 2 Two-way database replication | Both sites accept writes. This needs a database designed for it, or an application that splits data so each record has one home site. |
| 3 File and object replication | Uploaded files and objects are copied in both directions so either site can serve them. |
| Global load balancer | Sends each user to a site by location or weight, and stops sending users to a site that fails its health checks. |
Active-active is as much an application design as an infrastructure design. Web and application servers must be stateless, every operation must be safe to retry, and the database must cope with writes arriving at two places at once.
In practice, many systems described as active-active run the web and application tiers active-active and keep the database active-passive. That gives most of the benefit with far less risk, and it is often the right choice.
How failover works
- Health checks for one site fail.
- The global load balancer stops sending new users to that site. With DNS-based balancing, short TTLs keep this to seconds or minutes.
- The surviving site absorbs the full load, using the headroom it was sized with.
- No database promotion is needed if both sites already accept writes.
- When the failed site returns, it resynchronises and is added back gradually.
Failback: There is no separate failback. The repaired site catches up on data and the load balancer slowly returns users to it.
When to use it
- Large digital channels, SaaS platforms and internet-facing services
- Applications built or rebuilt as stateless services
- Organisations with mature operations and automated testing
When it is not enough
- Existing applications that keep state on the server or cannot be changed
- Databases that cannot accept writes at two sites safely
- Teams without the operational maturity to run two live sites
What to watch out for
- Data conflicts. Two users changing the same record at two sites at the same moment must be handled by design, not discovered in production.
- Headroom. Each site must carry 100% of the load alone. In normal running each is at most half used.
- Hidden single points. A shared licence server, identity provider or payment gateway at one site quietly breaks the design. Map every dependency.
- Testing. Regularly drain one site completely during business hours to prove the other can carry everything.
Typical tools for this pattern
Examples only. We recommend tools based on what you already run, your team's skills and your licences.
| Layer | Common choices |
|---|---|
| Traffic | Global server load balancing, anycast, cloud global load balancers |
| Application platform | Kubernetes clusters at both sites, managed with GitOps |
| Data | Distributed SQL databases (CockroachDB, YugabyteDB), MariaDB Galera, or application-level data partitioning |
| Sessions and messaging | Replicated Redis, Kafka with MirrorMaker 2 |
Comparing options? See all five patterns side by side in the DR patterns guide, or read what DR really costs.
Not sure where your DR stands?
Send us your application list and a short note on how backups work today. We will come back with a plain gap review: which systems are exposed, what a realistic recovery time looks like, and what it would take to close the gap.