Data-Plane Config Push
also called Config as Data Delivery, Runtime Rule Distribution
A change delivered to production as data on a fast distribution path rather than as a deployment - which escapes staged rollout and automatic rollback precisely because nobody classified it as a release.
A security rule reaches every edge location in seconds, by design, because the attack it blocks is happening now. The same path also carries broad rule-set updates whose risk is the entire fleet. One path for both delivers the risk profile of the second at the cadence of the first, and the result is an outage with no bad deployment in it.
A data-plane config push is any change that is distributed to running production systems as configuration and is then interpreted or executed there: rule sets, routing tables, policy expressions, query templates, pattern languages, scoring thresholds.
Why it matters
The delivery system's safety machinery is attached to deployments. Canary fleets, staged rollout, bake time, automatic abort and rollback all exist on the code path. A change that travels as data gets none of it, and the reason is a classification error rather than a technical limitation.
The second reason is that the fast path is correct. Removing it to prevent this class of incident trades a short outage for hours of exposure to an active attack. The answer is never one slower path; it is separate paths per urgency and risk class, which is the decision the incident teaches.
Third, the blast radius of a data push is often larger than any deployment's, because distribution is designed for speed and reaches the whole fleet simultaneously. Simultaneity is the property that makes it dangerous, independent of how small the change looks.
Implementation patterns
- Classify change types by urgency and risk, and give each a path. The emergency path stays fast and is restricted to narrow, machine-verifiable changes. Everything else goes staged.
- Make the dangerous property mechanically impossible rather than reviewed. For patterns, a linear-time matching engine or a complexity check before distribution. A reviewer cannot reliably spot catastrophic backtracking; a checker can.
- Resource guards at the point of execution. A CPU or wall-clock budget per evaluation, so a pathological input degrades one request rather than the machine.
- Stage even on a seconds-long schedule. A canary fleet taking 10 seconds of a 30-second propagation is still a canary, and it is the difference between global impact and partial impact.
- Automatic abort on a health signal, with the signal chosen so it moves within the propagation window — CPU, error rate, saturation.
- A tested kill switch for the subsystem, because recovery from a bad global push is to stop executing what was pushed.
- Simulate against recorded traffic before distribution, which catches resource-exhaustion defects that no amount of review will.
Industry example
In July 2019 a Cloudflare WAF rule containing a regular expression that backtracked catastrophically pegged CPU across the company's global network for roughly 27 minutes. The rule was data, it propagated in seconds by design, and the published account commits to staged rollout for that distribution path — which is the structural reading rather than treating the regular expression as the whole cause.
Fastly's June 2021 outage makes the adjacent point: a valid customer configuration triggered a latent software bug introduced in a May deployment, and most of the network returned errors for under an hour. Configuration was the trigger and code was the defect, which is why both paths need the same questions asked of them.
Failure scenarios
- Global simultaneous impact from one push, with no cohort left healthy to compare against.
- A pattern-language change exhausting CPU, where the cost is in the input rather than in the rule's size.
- An emergency path used for a non-emergency change, because it is the fast one and nobody classified the change.
- Rollback that is itself a push, so recovery takes as long as distribution and depends on the same system that is now saturated.
- A health signal too slow to abort within the propagation window, making the abort decorative.
- Configuration excluded from the change record, so the incident timeline shows "no deployments" and the investigation starts in the wrong place.
Trade-offs
| Choose | Gains | Pays |
|---|---|---|
| One fast path for everything | Minimal exposure to active threats | Global blast radius for every change class |
| One staged path for everything | Bounded blast radius | Hours of exposure during an attack; people route around it |
| Separate paths per class | Both properties where each is needed | Classification discipline; two mechanisms to build and test |
The classification discipline is the real cost, and it is ongoing: every new change type has to be assigned, and the incentive is always to use the fast path.
When not to use it
Most configuration does not need this. A feature flag for one tenant, a timeout value, a copy change, a scaling parameter: none is interpreted as a program, none consumes unbounded resources, and gating them all makes operations slower and pushes people towards out-of-band edits — which is strictly worse than where you started.
The trigger is all three properties together: interpreted or executed at runtime, distributed globally, and capable of consuming unbounded resources. Any two of them is not enough.
Interview question
Q: Your platform distributes rule-set updates to 200 edge locations in under 10 seconds. A security engineer asks for that path to be used for a new category of scoring rules that are evaluated per request. What do you ask, and what do you require before agreeing?
What a strong answer covers: establishing which urgency class the new rules belong to, and refusing to let risk class be inherited from the path · the three properties that make a config push dangerous, and checking the new rules against them — are they interpreted at runtime, globally distributed, and resource-unbounded · requiring a per-evaluation resource budget and a static complexity check before distribution rather than review · requiring a canary cohort inside the propagation window with an automatic abort on a signal that moves fast enough to matter · requiring a tested kill switch for the new category specifically · recording the push in the change log so an incident timeline shows it · and the honest alternative: if the rules are not urgent, they belong on the staged path and the conversation is over.
Quick check
Quiz: Why did a 27-minute global outage have no bad deployment in it? — The change travelled as configuration on a path built for seconds-scale propagation, so it bypassed the staged rollout, canary and automatic rollback that the code path had.
Flashcard: Which three properties together mean configuration needs deployment-grade controls? — It is interpreted or executed at runtime, distributed globally, and able to consume unbounded resources. A timeout value has none of them.