Runtime Feature Flags for Zero‑Downtime Deployments

Decision and Constraints

The post‑deployment behavior of a feature must be controllable without requiring a full redeploy or downtime. The goal is to adopt a runtime feature‑flag mechanism that satisfies three constraints: zero‑downtime rollout, minimal operational overhead, and easy rollback.

Option Comparison

Three common ways to implement a flag are shown in the table below. Each option influences deployment impact, operational complexity, and rollback simplicity.

Option	Deployment Impact	Operational Complexity	Rollback Ease	Typical Overhead
Compile‑time #ifdef	Requires a new build and redeploy	Low – flag is baked into the binary	Hard – must rebuild to change state	Zero runtime cost
Static config flag (e.g., Spring property)	May need a JVM restart if the property changes	Low – simple property file edit	Easy – change property and restart	Negligible runtime cost
External flag service (e.g., Spring Cloud Config, LaunchDarkly)	No code change; updates propagate via config refresh or API	Higher – depends on network, service availability	Very easy – toggle via service UI or API	Network latency and single point of failure

Compile‑time flags eliminate runtime cost but force a redeploy for any change, violating zero‑downtime. Static config flags are simple but require a restart, which can interrupt traffic. External services avoid restarts but introduce network latency and a potential single point of failure.

Concrete Implementation

In a Spring Boot application the flag can be stored in application.yml as a Boolean property.

# application.yml
feature:
  new‑ui:
    enabled: false

The property is injected with @Value and used in a utility method that guards the feature code.

import org.springframework.beansfactory.annotation.Value;
import org.springframework.stereotype.Component;

@Component
public class FeatureGuard {

    private final boolean enabled;

    public FeatureGuard(@Value(\"${feature.new-ui.enabled}\") boolean enabled) {
        this.enabled = enabled;
    }

    public boolean isEnabled() {
        return enabled;
    }
}

The guarded method checks the flag before executing the feature logic.

public void executeFeature() {
    if (featureGuard.isEnabled()) {
        // feature implementation
    } else {
        // fallback or no‑op
    }
}

Because the flag is read from configuration, toggling feature.new-ui.enabled to true and refreshing the Spring context (e.g., via Spring Cloud Config) activates the feature instantly, without restarting the JVM.

Why this approach works for zero‑downtime:

• The application continues running while the flag value changes.
• No code recompilation or JVM restart is required.
• Rollback is as simple as setting the flag back to false and refreshing config.

Limitations to keep in mind:

• Compile‑time #ifdef offers zero runtime cost but eliminates the ability to toggle after deployment.
• Static config flags need a restart; if the feature must be enabled immediately, this violates the zero‑downtime requirement.
• External flag services add network latency and depend on the availability of the service; a failure there can make the flag unusable.

Verification and Risks

To ensure the flag behaves as intended, follow these verification steps.

• Write unit tests that assert featureGuard.isEnabled() returns false when the property is false and true when true. Run the tests in the CI pipeline. Example test snippet:

@Test
void flagIsDisabledWhenPropertyFalse() {
    // arrange
    FeatureGuard guard = new FeatureGuard(false);
    // act
    boolean result = guard.isEnabled();
    // assert
    assertFalse(result);
}

• Deploy the application to a staging environment. Edit application.yml to set feature.new-ui.enabled to true, then trigger a config reload. If you use Spring Boot Actuator, the command is:

curl -X POST http://localhost:8080/actuator/refresh

Run a functional test that exercises the feature and verify the outcome matches the flag state. If the test passes, the implementation meets the zero‑downtime and low‑overhead requirements.

Monitor logs or a health endpoint to confirm the feature code path is taken or skipped as expected. Example log statement:

log.info(\"New UI feature enabled: {}\", featureGuard.isEnabled());

Key cautions:

• Mis‑configuring the flag can leave a feature permanently enabled, exposing security or performance risks. Document the purpose of each flag and include a review step before promoting to production.
• Relying on an external flag service introduces a network dependency; ensure the service is highly available and consider a fallback to a local property for critical features.
• Static config flags require a JVM restart to take effect, which may conflict with zero‑downtime goals. Use this approach only when restarts are acceptable.

Practical check: after toggling the flag, run a canary test that routes a small percentage of traffic to the new feature and verify correct behavior. If the canary succeeds, the flag implementation is ready for broader rollout.