Multi-Cloud Replication & Failover

Traffic

Write rate 1.0/s

Replication latency 300 ms

Auto-failover ON

Providers

Live metrics

Active primary

AWS

Availability

100.0%

In sync

2 / 2

Failovers

Booting cluster…

How it works

Three independent cloud providers each hold a replica of the same data. One is elected primary and accepts writes; the others are secondaries that receive an asynchronous copy after a network delay L (the replication latency slider). This is the standard "eventual consistency" model used by real multi-cloud and multi-region deployments.

write(v) at primary  →  version[primary] += 1
after delay L(ms)     →  version[secondary] = version[primary]
consistency = (# secondaries in sync) / (# healthy secondaries)

Killing the primary simulates a real provider outage (a region going down, an API blackout, a cut fibre). With Auto-failover on, the cluster promotes the next healthy provider to primary — the same logic behind DNS/anycast failover and cloud load-balancer health checks. With it off, writes queued for a dead primary simply fail, which is what an application without a failover strategy would experience.

Availability — fraction of elapsed time at least one provider was healthy and reachable.
In sync — how many healthy secondaries currently hold the same version as the primary; a bigger replication-latency value or higher write rate widens this gap.
Reviving a downed provider triggers an immediate catch-up replica so it can rejoin quickly, mirroring a real "resync on rejoin" strategy.

This trade-off between consistency, availability and tolerance to network partitions is formalised as the CAP theorem: a distributed system can only fully guarantee two of the three at once.

AWS Azure GCP Client write

⚠ Couldn't load the 3D engineThree.js failed to load from the CDN. Check your connection and reload.

Multi-Cloud Replication & Failover Simulator