Stay up when others are down
01 · The architecture of 99.999%
Architecture
You describe a workload once, and it runs in every location you choose. When one location goes down, the other locations keep serving.
On Control Plane, one Global Virtual Cloud spans AWS, GCP, Azure, OCI, bare metal or any other cloud or neocloud, in any region. The platform geo-routes each user to the nearest healthy endpoint.
- Geo-DNS. Answers each request with the nearest healthy location. Priority groups allow for routing configurability.
- Readiness probes. A replica gets traffic only after its probe passes, and leaves the pool when it starts failing.
- Multi-zone replicas. Replicas spread across availability zones inside each location, so one zone can fail quietly.
- Standby tier. Any location can sit on a lower routing tier as a standby. It runs the same workloads and takes traffic only when every location ahead of it is down.
cpln apply --file gvc.yaml
kind: gvc
name: production
spec:
staticPlacement:
locationLinks:
- //location/aws-us-east-1
- //location/gcp-us-east1
- //location/azure-eastus2
locationOptions:
- locationLink: //location/aws-us-east-1
routingTier: 0
- locationLink: //location/gcp-us-east1
routingTier: 0
- locationLink: //location/azure-eastus2
routingTier: 1
aliasWorkloadLink: //workload/api
Apply it from the console, CLI, Terraform, Pulumi or the API.
Survive zone, region, or whole cloud failure
Control Plane keeps you serving whether a zone, a region or an entire cloud goes down. One Global Virtual Cloud can span more than one provider, so no single failure takes out every location.
Availability zone
One data center loses power or network.us-east-1bus-east-1a Covered by multi-zone replicas.
Region
Services inside a region share dependencies and fail together.us-east-1us-west-2 Covered by a second location.
Provider
Global services and shared management layers fail across every region at once.awsazure Covered by a location on another provider.
Failover that runs above every cloud
When a zone, region or provider fails, traffic moves to locations that are already running, and autoscaling adds capacity there as load arrives. Routing, health checks and identity all run outside any single provider, so failover keeps working even when a cloud’s own services are down.
02 · The data model of 99.999%
Data
Your data is replicated across every location. Control Plane database templates come with replication already configured, so you configure resilient data instead of building it.
Every location already runs your services, so stateless compute recovers in seconds. Databases replicate between locations as writes come in, so the data is already there when traffic moves.
| What fails over | Recovery target | What sets it |
|---|---|---|
| Stateless compute | RTO near zero | Every location is already serving, and routing only sends traffic to replicas that pass readiness. |
| Template databases | RPO near real time | Replication comes configured in the template, so each write reaches the other locations within a fraction of a second. |
| Managed cloud databases | RPO near real time | Services like Google Cloud Spanner replicate across regions themselves, and every location reaches them through Universal Cloud Identity. |
Four ways to protect your data
“Control Plane positively impacted our daily operations by enabling us to host services in multiple regions with 99.999% availability and ultra-low latency — enhancing our customer trust.”
03 · The settings of 99.999%
Settings
The settings decide how quickly a failure is caught and routed around, and how many replicas keep serving while you deploy.
The architecture decides whether you can fail over. These settings decide how it plays out. Detection pulls a failing replica from the pool, Routing picks which locations serve first, Deploys pace each rollout, and Capacity spreads replicas across zones and sets the minimum in each location.
With the defaults, a failing replica leaves the pool in about 30 seconds: one check every 10 seconds, three failed checks.
| Setting | What it does |
|---|---|
| Detection | |
| readinessProbe. | How often each replica is checked.Default 10s · 1–60 |
| readinessProbe. | Failed checks before a replica leaves the pool.Default 3 · 1–20 |
| livenessProbe | Restarts a replica that is running but stuck. |
| Routing | |
| routingTier | Which locations serve first. Tier 0 is the top tier; a location on a lower tier, such as tier 1, takes traffic only when every tier 0 location is down. |
| aliasWorkloadLink | The Global Virtual Cloud's alias endpoint follows your workload's readiness probes instead of a TCP check on the ingress. |
| latencyOffsetMs | Biases traffic toward or away from a location. |
| latencyToleranceMs | Treats a location as unavailable if latency exceeds the configured threshold. |
| Deploys | |
| rolloutOptions. | The docs recommend 100% when you need a short cutover. |
| rolloutOptions. | Caps how many replicas can be down during a rollout or rescheduling. |
| rolloutOptions. | How long a new replica runs before the rollout moves on. |
| rolloutOptions. | Time to drain open connections before a replica shuts down. |
| Capacity | |
| defaultOptions. | Spreads replicas across availability zones. Cross-zone charges apply. |
| autoscaling. | Can go to 0. We recommend 2 or more in every location, so a standby tier is never cold and one lost replica never empties a location. |
Then prove it, on a schedule
Move one location to a lower routing tier, or take it out of the Global Virtual Cloud.
Watch DNS answers shift with dig, and track error rates from outside your own network.
Restore it, and write down how long the move took from your users' side.
Five nines, without building it yourself
Book a demo and we'll walk through where your stack fails over today, and what it looks like as one Global Virtual Cloud.