Choosing between active-active and active-passive disaster recovery affects recovery time, data loss, operating cost, and the complexity of your hosted application. This guide explains the trade-offs, provides a repeatable estimation method, and includes a design worksheet and quarterly failover-test checklist for websites, SaaS platforms, ecommerce stores, and databases.
Overview
Active-active and active-passive are two ways to distribute an application across separate data centres or hosting regions.
In an active-active design, two or more environments serve production traffic at the same time. Traffic may be divided by geography, capacity, user group, or a load-balancing policy. The design can provide fast recovery because the second environment is already running, but it requires careful handling of data replication, sessions, queues, background jobs, and conflicting writes.
In an active-passive design, one environment serves production traffic while a second environment is kept ready for recovery. The passive site may run continuously, run at reduced capacity, or be started when a disaster occurs. This approach is usually simpler to reason about, but recovery depends on detecting the incident, promoting systems, restoring or attaching data, and directing traffic to the recovery site.
| Factor | Active-active | Active-passive |
|---|---|---|
| Typical RTO | Low when traffic and dependencies are already ready | Depends on detection, promotion, startup, and traffic changes |
| Typical RPO | Can be very low, but depends on replication and conflict handling | Depends on the replication interval and the last usable backup or replica |
| Database replication | Often requires multi-writer controls, partitioning, or carefully designed single-writer patterns | Often uses a primary with a replicated standby or restored backup |
| Failover complexity | High: both sites must work during normal operation | Moderate to high: promotion and recovery procedures must be rehearsed |
| Cost | Higher because production capacity and dependencies may be duplicated | Potentially lower, especially when the recovery site uses reduced capacity |
| Consistency | Requires explicit decisions about stale reads, write conflicts, and ordering | Often easier to keep a single authoritative write path |
| Operational overhead | Continuous monitoring, deployment parity, and cross-site coordination | Regular replication checks, runbooks, and scheduled failover tests |
Neither model is automatically safer. A well-tested active-passive architecture can be more dependable than an untested active-active system. Conversely, an active-active design may be appropriate when the application needs continuous service across regions and can tolerate the engineering required to keep both sites consistent.
How to estimate
Start with business requirements rather than a preferred hosting pattern. Define the maximum acceptable recovery time objective (RTO) and recovery point objective (RPO).
- RTO: the target maximum time to restore an acceptable level of service after a failure.
- RPO: the target maximum amount of recent data that may be lost, measured by time.
Then estimate each architecture using the same categories:
- Compute readiness: Is the recovery environment already running at production capacity, running at reduced capacity, or created during recovery?
- Data readiness: How current is the replica or backup? Include replication lag, backup completion time, restore time, and validation time.
- Traffic control: How will users reach the surviving site? Document DNS, global load balancing, reverse-proxy, application-routing, or manual changes and allow for caching and client behaviour.
- Dependency recovery: Include identity services, payment gateways, email, object storage, queues, third-party APIs, secrets, certificates, monitoring, and administrative access.
- Verification: Add time to run health checks, test key transactions, confirm data integrity, and decide whether to open the site fully.
A practical RTO estimate is:
RTO estimate = detection time + decision time + promotion or startup time + traffic-switch time + validation time
A practical RPO estimate is based on the oldest data that can be recovered reliably. For replicated systems, use measured replication lag rather than the configured interval alone. For backups, include the backup schedule, whether the latest backup completed successfully, and the time required to restore and validate it.
For cost comparison, list recurring and variable costs separately. Recurring costs may include the second hosting environment, storage, replicated databases, cross-data-centre network transfer, monitoring, security controls, and support. Variable costs may include temporary recovery capacity, emergency engineering time, data restoration, and post-incident investigation. Use your provider quotations and measured usage rather than generic market prices.
Inputs and assumptions
Use this worksheet before selecting a hosting failover architecture:
- Application: website, SaaS platform, ecommerce store, API, or database service.
- Critical user journeys: identify the transactions that must work during recovery, such as login, checkout, publishing, or account updates.
- Target RTO: record the maximum acceptable interruption for each service tier.
- Target RPO: record the maximum acceptable data loss for each data type.
- Traffic profile: note normal, peak, and recovery capacity requirements.
- Write model: identify whether one site, both sites, or a controlled queue can accept writes.
- Replication method: record the database, storage, backup, queue, and configuration replication tools in use.
- Consistency requirement: specify whether stale reads, duplicate jobs, or temporarily unavailable writes are acceptable.
- Recovery location: document region, data residency constraints, connectivity, and any dependency on a particular data centre.
- People and access: identify who can declare a disaster, promote systems, change routing, and approve service restoration.
Separate an outage of the application from an outage of the hosting site. A multi-data-centre design does not protect against application defects, bad deployments, compromised credentials, corrupted data, or a replicated mistake. Keep independent backups, restrict administrative access, and include a recovery method that does not depend solely on the production control plane.
For websites and content platforms, active-passive may be sufficient when the primary concern is data-centre loss and the application can tolerate a controlled recovery window. For ecommerce, examine order creation, payment status, stock updates, refunds, and fulfilment events; duplicate or missing transactions can be more damaging than a short read-only period. For SaaS platforms, consider tenant routing, scheduled jobs, webhooks, customer-specific data, and the ability to prevent two sites from processing the same work. For databases, define the authoritative writer and test promotion, rollback, split-brain prevention, and integrity checks.
Worked examples
Example 1: Content website
A content website has a primary environment and a second environment in another data centre. The database is replicated, media files are copied, and traffic can be redirected through the hosting provider's routing layer. The recovery site does not need to serve normal traffic.
The estimate should measure detection, replica promotion, cache and application startup, routing changes, and editorial verification. If the target RPO is modest, active-passive can avoid the complexity of accepting writes in both locations. The runbook should specify how publishing is paused, how the last consistent database position is identified, and how editors are notified.
Example 2: Ecommerce store
An ecommerce store may use active-active web and application tiers while retaining a controlled database write path. This can reduce the impact of a regional web-tier failure without requiring every data operation to be multi-writer. The design must still address carts, payment callbacks, inventory reservations, queues, and order numbers.
Estimate the cost of duplicated application capacity separately from the cost of database resilience. Test a partial failure, such as one application region becoming unavailable, and a full data-centre failure. A temporary read-only mode may be a valid recovery state if it prevents incorrect orders while the authoritative data service is promoted.
Example 3: SaaS database service
A SaaS platform with strict tenant data requirements should begin by mapping data ownership and write dependencies. Active-active may be justified when customers require service continuity across locations, but it can introduce conflict resolution and operational overhead. An active-passive design may provide a clearer consistency model if the business can accept a longer RTO.
Compare both designs using measured failover time, replication lag, recovery capacity, engineering effort, and the result of a real restore test. Do not treat a successful infrastructure health check as proof that customer transactions are safe.
When to recalculate
Revisit the decision whenever the inputs change, not only after an outage. Recalculate after a major application release, database migration, traffic increase, new data residency requirement, hosting-provider change, or alteration to payment, identity, storage, or queueing dependencies. Provider capabilities, replication tooling, platform versions, network pricing, and available recovery options can also change, so review the assumptions before renewing a hosting arrangement.
Run a quarterly failover review using this checklist:
- Confirm that recovery contacts, credentials, certificates, DNS or routing access, and provider support details are current.
- Verify replication status, backup completion, retention, restore permissions, and the location of independent copies.
- Test the runbook in a controlled environment, including promotion, traffic switching, health checks, and rollback.
- Perform at least one scenario test that includes a dependency failure or a corrupted deployment, not only a clean server outage.
- Measure actual RTO and RPO results and compare them with the worksheet targets.
- Check that monitoring detects both total failure and silent replication or consistency problems.
- Record unresolved issues, assign owners, and set a date for retesting.
Use the results to choose the least complex architecture that meets the business requirement. For additional planning, compare your recovery location and connectivity assumptions with the guidance in choosing a data centre location for low-latency hosting, and review the practical migration controls in the guide to moving a website or server with minimal downtime. The goal is not to operate the most elaborate design; it is to recover verified service and trustworthy data within an agreed limit.
