Traefik Dynamic Config Reload Atomicity Limits

Traefik supports hot reloading of dynamic configuration via the API or file watcher, enabling routing changes without restarting the proxy. This capability is often relied upon for zero-downtime migrations of small applications, but the exact behavior of request routing during the reload transition is not fully specified in general documentation.

The reload process is not strictly atomic. Ongoing requests may continue to use the pre-reload configuration while new requests are routed according to updated rules, which can produce split traffic or temporary routing inconsistencies. The --graceful flag ensures no new connections are accepted after SIGTERM, but it does not coordinate with configuration reload to avoid race conditions. Reload timing is influenced by the provider's update frequency and the proxy's internal reload loop, and behavior may vary between Traefik v2.x and v3.x.

For a migration without downtime, the unresolved decision is whether operators can rely on any ordering or isolation guarantee for in-flight requests during a dynamic configuration change, or whether they must design around a non-deterministic overlap window.

Does Traefik v3 offer stronger atomicity for dynamic configuration reloads than v2.x? Is the overlap between old and new routing rules bounded and observable, or does it vary by provider? What is the supported approach to preserving request consistency during a migration when --graceful does not coordinate with reloads?