During a peak event, a platform's configuration service becomes unavailable. What should happen to the serving path, and what design property is being tested?

The property

Static stability: the serving path continues on its last known good state when its control components are unavailable. The system does not get better during the outage — it cannot scale, deploy or reconfigure — but it does not get worse.

What that requires

• Configuration cached locally with an indefinite soft expiry. The failure mode must be "use the previous value", never "fail". This has to be the explicit default, because the natural implementation of a configuration fetch is to fail when it cannot fetch.
• No synchronous control-plane call on the request path. Feature flags, limits, routing and entitlement checks are all read from local state that is refreshed in the background.
• Pre-provisioned capacity, because a peak event's ramp is faster than any scaling loop and scaling is exactly what a control-plane outage removes.
• Health checks that reflect the serving path, not the control plane, so a control-plane outage does not cause instances to be removed from rotation while they are serving perfectly well.

Why peak events make this acute

The control plane is under its own maximum stress at exactly the same time, because scaling activity, configuration changes and deployments cluster around the event. A design where the serving path depends on it has correlated the two failures, so the control plane fails when it is most loaded and takes serving with it.

The tension to resolve deliberately

Some configuration must propagate quickly even during an outage: disabling a broken feature, blocking an abusive client, applying an emergency limit. That conflicts directly with indefinite caching.

The resolution is two classes: ordinary configuration cached indefinitely, and a small emergency-control channel with a short TTL and a fail-safe posture. Keeping the second small is what makes it affordable to fetch frequently and safe to depend on.

The test that proves it

Turn the control plane off during a load test and observe. Most teams discover that something on the request path calls it — an authorisation check, a limit lookup, a flag evaluation — and that discovery during a test is worth considerably more than the same discovery during the event.