New domains, certificate renewals, cache TTL changes and security policy all affect edge behavior. A direct but fragile design is to query the management backend for current configuration while handling a request. Backend latency or failure then becomes a delivery problem.
IXCDN separates the two paths. The console edits and publishes configuration. A change becomes an identifiable version before edge locations receive it, and a location that has loaded a valid version does not need a console response for every request.
Saved, published and applied configuration states
Consider enabling HTTPS for a domain while changing the cache TTL for its static assets. The operator needs to distinguish three states:
- The new configuration has been saved.
- A new version is being published or has finished publishing.
- Edge locations are serving requests with that version.
A “saved” message covers only the first state. Recording the version and rollout separately makes it possible to tell whether an unexpected result came from editing, publication or location loading.
Versioned publication and configuration atomicity
Certificates and cache rules are separate objects, but an operator may need them to take effect as one change. If a location sees the new cache rule before the certificate, or receives only part of the update, live behavior becomes hard to explain. A version gives the team one unit to inspect: this set of domain, certificate, cache and security configuration belongs to the same change.
Version history also provides a basis for rollback. When something fails, the team can identify which locations loaded which version, then continue the rollout, correct the configuration or restore the previous known-good version instead of inferring state from edit timestamps.
Data-plane behavior during control-plane unavailability
Edge locations that already hold valid configuration continue serving with it. New changes may not be available during the interruption, but existing traffic does not need to call the management backend for each request. That is the practical benefit of separating control and data planes: a management failure does not automatically become a delivery failure for existing workloads.
This design does not make an incorrect rule safe. Teams still need to check certificate coverage, cache boundaries and security policy before publication, then verify status codes, logs and hit ratio afterward. Versioned delivery addresses completeness, traceability and runtime dependency; it does not replace release review.