A deployment platform's control plane goes down. What should happen to customer applications already serving traffic, and what does that requirement force into the architecture?

The property being bought

Static stability: the data plane continues operating on its last known good state when the control plane is unavailable. A platform without it has capped its own reliability at the reliability of its least important administrative endpoint — a deploy of the billing API becomes a customer outage.

What it forces into the design

• Routing configuration is pushed to the edge and cached locally, not pulled per request. The proxy holds the current mapping and serves from it indefinitely.
• Authentication and authorisation decisions on the data path use locally verifiable material — signed tokens with embedded claims — rather than a call to an identity service. A token that must be validated by a remote lookup makes that service a hard dependency of every request.
• The failure mode is "serve the previous configuration", never "fail". This has to be the explicit default in the proxy, because the natural implementation of a config fetch is to fail when it cannot fetch.
• New deployments, scaling changes and configuration updates stop. That is the acceptable degradation, and stating it clearly is part of the design.

The tension this creates

A configuration change that must propagate quickly — revoking a compromised credential, blocking an abusive customer, removing content under legal order — conflicts directly with a data plane that ignores the control plane when it is unreachable.

The resolution is two propagation classes. Ordinary configuration is eventually consistent and cached indefinitely. Security-critical revocations use a short-lived, fail-closed path with a small blast radius: a revocation list with a short TTL, where the failure to refresh means denying rather than allowing.

The related risk

A bad configuration propagates just as fast as a good one. A platform capable of pushing a change to thousands of edge locations in seconds is capable of pushing an outage to thousands of edge locations in seconds. That requires validation before propagation, staged rollout by region with automated halt conditions, a fast rollback path that does not depend on the same pipeline, and a version scheme so "roll back to the last known good" is a well-defined operation.