Why Cold-Standby Disaster Recovery Fails and How Active‑Active Architecture Wins

In a previous article I argued that cold‑standby or primary‑secondary disaster‑recovery models are rarely effective in real failures; they often serve only as psychological reassurance.

Recent public‑cloud incidents have sparked two common reactions: the belief that a single site is unreliable and must be backed up, and the claim that “you shouldn’t put all eggs in one basket” – i.e., you need multiple clouds, often promoted as a vendor’s multi‑cloud service.

Both viewpoints miss key complexities. The first assumes building a standby site is simple, while the second ignores technical constraints.

To choose a proper disaster‑recovery strategy, we must first understand the terminology and then evaluate suitability.

Active‑Active (dual‑active) architecture means two sites simultaneously serve traffic, routing requests based on user ID, region, or other attributes. When one site fails, traffic can be switched within minutes, ideally without data loss.

This differs from primary‑secondary, where the secondary never handles traffic.

Active‑active can be implemented at different layers: either the entire stack runs within a single data center (closed‑loop) or only the stateless application layer is dual‑active while stateful components (databases, message queues) remain on the primary site. The latter still requires data‑layer failover, which is costly and time‑consuming.

Effective active‑active requires three technical pillars:

Local (same‑site) calls : Distributed requests must not cross data‑center boundaries; routing, service frameworks, data access, and messaging must all support intra‑site closed loops.

Data partitioning and consistency : Data must be sharded so that each site handles a distinct subset of users, preventing concurrent modifications of the same record. This demands distributed data middleware, routing logic, and strict read‑write locality.

Data synchronization : Even with sharding, timely cross‑site data sync is essential. Physical latency becomes the dominant challenge; as distance grows, network hops and protocol conversions can increase round‑trip times from sub‑millisecond to seconds.

Physical distance limits the feasibility of active‑active across regions. For example, Alibaba’s Hangzhou‑Shanghai dual‑active setup faces significant latency, and cross‑province links can be unpredictable, especially when using third‑party data centers.

Data‑sync latency directly impacts business experience: inventory visibility must be consistent, and transaction loss during a failure can be catastrophic for high‑throughput systems.

Consequently, without robust data partitioning, synchronization, and intra‑site call guarantees, any claim of active‑active or multi‑active is unrealistic.

Practical rollout often follows a staged cadence: same‑city dual‑active → cross‑city dual‑active → multi‑city three‑center architecture, reflecting increasing complexity and cost.

Ultimately, the decision hinges on ROI: higher availability incurs higher expense, and each organization must assess whether the benefits outweigh the costs.