Static Stability
Practical example
An Envoy fleet configured via xDS continues routing traffic using its last-received cluster and route configuration when the control-plane management server becomes unreachable during a deployment, rather than failing requests or clearing its routing table, while local active health checks still evict genuinely dead upstream pods.
Static Stability is a design discipline popularized by AWS’s Well-Architected guidance, distinguishing between a system’s control plane (the infrequent, mutation-heavy path: scaling decisions, configuration pushes, DNS updates, autoscaling group changes) and its data plane (the high-frequency, read-heavy path: serving requests). A statically stable system is one where the data plane never issues synchronous, blocking calls to the control plane during steady-state operation or during a control-plane degradation. Instead, it operates entirely off of a locally cached or pre-fetched snapshot of state that was resolved before the failure began.
The canonical failure mode this pattern defends against is a control-plane retry storm: when a dependency like a service discovery system, IAM token service, or configuration store degrades, naive clients that re-fetch state on every request (or on every cache-miss/TTL-expiry) will hammer the already-degraded dependency with retries, worsening the outage and potentially causing cascading failure into unrelated systems that share that control plane. Statically stable designs instead extend TTLs indefinitely on failure (fail open on staleness rather than fail closed on absence), keep a last-known-good configuration resident in memory or on local disk, and treat control-plane unavailability as a signal to freeze state rather than a signal to escalate refresh attempts.
Concrete implementations include: DNS resolvers caching records well past TTL rather than blocking on re-resolution; EC2 Auto Scaling Groups that keep existing instances running (and load balancers keeping them registered) even if the ASG control plane itself is unreachable; Envoy/xDS clients that continue routing on the last-applied configuration snapshot when the management server is unreachable, rather than draining routes to zero; and Kubernetes kubelets that keep running already-scheduled pods even when the API server is unreachable, only failing new scheduling operations. The unifying principle is graceful degradation of the control plane must not propagate into the data plane — the system should degrade in capability (no new deployments, no scaling changes, no config updates) while degrading in availability as little as possible.
The main architectural cost is staleness risk: a statically stable system may keep routing to an unhealthy backend or serving an outdated feature flag for the duration of the outage, trading correctness/freshness for availability. This must be paired with independent, local health-checking (e.g., data-plane-level circuit breakers or passive health checks) so the system isn’t blindly serving traffic to backends that are actually dead, merely unreachable from the control plane’s perspective. Testing this property requires explicit chaos experiments that sever control-plane connectivity while measuring whether the data plane’s steady-state SLOs hold.