What is static stability, and how do you design for it?

Static stability is a design property where a system keeps doing what it was already doing when a dependency becomes impaired. It may stop seeing new updates, but existing work continues. You get it by preparing capacity and data ahead of time, so recovery never needs the failing dependency.

The idea in plain words

AWS describes a statically stable design this way: the overall system keeps working even when a dependency is impaired, perhaps without seeing new or changed information the dependency was meant to deliver, while everything it was doing before continues to work.

The contrast is a reactive design. A reactive design notices a failure, then launches replacements, fetches configuration, registers with discovery services and acquires credentials. Every one of those steps is a new dependency, taken at the moment the environment is least healthy.

Reactive versus statically stable

The trade-off is real. A statically stable design holds capacity you hope not to use. The AWS article gives an example of three zones with 50 percent extra capacity, so that each zone runs at about two thirds of its load-tested level and any one zone can be lost without launching anything.

How a small team applies it

You do not need a cloud provider's scale to use the idea. Work through your own system in this order.

1. List the things your service does while running, such as serving requests, reading configuration, checking a license or calling an identity provider.
2. For each, ask what happens if the supplier of that thing is unreachable for an hour. Does the service stop, degrade, or carry on with the last known value?
3. Where it stops, store the last known good value locally. Configuration, feature flag states, signing keys and allow lists are common candidates.
4. Check your scaling plan. If a failure means you must start new instances to survive, you have a reactive design. Consider keeping spare capacity running for the parts that matter most.
5. Test it. Block the dependency in a staging environment and watch what the service does.

Step 3 has a security edge. A cached value can go stale, so decide how long it may be trusted and what happens afterward. A revocation list that is never refreshed is a risk of its own, so set an age limit and an alert.

Where static stability does not help

It protects existing work, not new work. If the failing dependency is the one that creates new users, deploys new versions or issues new certificates, those actions will wait. That is acceptable for many services for a few hours, provided you have decided it on purpose and written it down.

It also does not replace backups. A statically stable service survives a zone failure; it does not survive deleted data. Pair it with tested restores.

A worked example: a small web service

This example is hypothetical, to show the method. A team runs a web application with three parts: a stateless web tier, a database with a standby, and a background worker that pulls jobs from a queue. They sit down for an hour and ask what each part does when one supplier goes quiet.

Two findings stand out. The worker fetches a credential on every job, so a secrets outage stops work that could have continued. The fix is to cache the credential for a short, defined period and refresh it in the background. The web tier cannot scale during a problem with the orchestrator, so the team decides to hold some headroom: enough instances that the loss of one zone does not require launching anything.

Neither fix is dramatic. Both are decisions made on a calm afternoon rather than during an incident.

Step by step: turning findings into changes

1. Draw the request path for your most important user action, from the first click to the last write.
2. Under each box, list what it needs while running, and separately what it needs to start. Starting is where hidden dependencies live.
3. Mark every need that is fetched live on each request. These are candidates for caching with an age limit.
4. Mark every recovery step that says "launch", "create", "provision" or "register". Ask whether capacity can be ready ahead of time instead.
5. For each cache you add, write the maximum age and the behavior when it expires. A short expiry that fails closed is often right for security data.
6. Add a test in staging that blocks each dependency in turn. Record the observed behavior in a table like the one above.
7. Revisit after any architecture change.

Trade-offs to discuss openly

Static stability costs something. Held capacity sits idle most of the time. Caches can serve out of date values. Local copies of configuration can drift from the source. Say these costs out loud and decide per service, so nobody is surprised later. A useful framing is the question: what is an hour of this being unavailable worth, compared with the cost of holding a bit more in reserve?

Also keep security in view. A cached allow list or key set that never refreshes may keep a revoked entry alive. Pair each cache with an alert that fires when refresh has failed for longer than you tolerate, so a quiet failure becomes a visible one.

Try it yourself

Open the dependency inventory demo and look at how a service's components are listed. Pick one and ask the question from this post: what does it need while running, and what happens if that is unavailable?

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Static stability using Availability Zones (AWS Builders Library)
• Control planes and data planes (AWS Fault Isolation Boundaries)

Last reviewed: 19 October 2026.