Revocation Path

Static stability requires the data plane to keep serving from cached configuration when the control plane is unreachable, with an indefinite soft expiry. That is correct for routing, feature configuration and capacity settings.

It is exactly wrong for revocation. A compromised credential, an abusive customer, or content under a legal removal order must stop being honoured quickly, and a cache that ignores an unreachable control plane will keep honouring it.

The resolution is two propagation classes rather than one.

Why it matters

A single configuration channel forces a choice between availability and revocation speed, and whichever is chosen is wrong for the other case. Systems that pick availability discover during a security incident that they cannot revoke; systems that pick fail-closed discover during a control-plane outage that they have taken themselves down.

Implementation patterns

• Ordinary configuration: pushed, cached indefinitely, eventually consistent, fails to last-known-good.
• Revocation: a small, short-TTL list fetched frequently, where failure to refresh means denying rather than allowing. The blast radius is bounded because the list is small and its scope is narrow.
• Keep the revocation payload tiny, so it can be fetched often and cheaply and so a fail-closed posture is affordable.
• Short-lived credentials as the primary mechanism, with revocation as the exception path. A token that expires in minutes limits the damage without needing a revocation channel at all, and it is the more robust design.
• Validate before propagation, and stage the rollout. A bad configuration propagates as fast as a good one — anything that can push a change to thousands of edge locations in seconds can push an outage there in seconds.
• A rollback path that does not depend on the same pipeline, and a version scheme so "roll back to last known good" is a well-defined operation rather than a reconstruction.
• Automated halt conditions on the rollout, triggered by error rate or health signals rather than by a human noticing.

Industry example

Edge platforms such as Vercel and Cloudflare-shaped architectures face both sides of this: the data plane must survive control-plane outages, and a revocation must reach every location quickly. The two-class design is what reconciles them, and the staged-rollout discipline is what prevents the propagation capability from becoming the outage mechanism.

The same tension exists in any system with cached authorisation: a permission removed centrally must take effect before the cache expires, or the cache TTL is effectively the revocation SLA.

Failure scenarios

• One configuration channel, so revocation speed and availability cannot both be met.
• Cached authorisation with a long TTL, making the TTL the revocation window by accident.
• A large fail-closed payload, so a fetch failure denies broadly and causes an outage.
• Global propagation with no staging, turning a bad config into a global incident in seconds.
• Rollback through the same pipeline that is broken.
• No automated halt, so the rollout completes before a human reacts.

Trade-offs

A fail-closed channel is, by construction, a component whose failure denies service. That risk is managed by keeping it small, keeping its scope narrow, and giving it its own high-availability path — but it cannot be eliminated, and it is the price of being able to revoke.

The alternative — accepting that revocation takes as long as the cache TTL — is defensible for low-risk configuration and indefensible for credentials, which is why the classes are separated by risk rather than by convenience.

Interview question

"A customer's API key is leaked publicly. How long until every edge location stops accepting it, what in your architecture determines that number, and what would you change to make it shorter without making a control-plane outage into a customer outage?"