Learning goal: design a feature flag so that disabling it is a predictable operational action rather than another failure mode.

A switch is not a rollback plan

Fictional educational scenario. A public-service portal processes applications. A new automatic data prefill is enabled for 10% of users, with a planned increase to 50%. The team controls it with a flag named new-prefill. An hour later, malformed applications begin to rise. An operator turns the flag off, but some workers still use cached evaluations and queued jobs were already created under the new rules.

A flag selects a code path. It does not reverse business effects that have already occurred. The ability to flip a switch is therefore not, by itself, a rollback strategy.

Three decisions before rollout

  1. Where is the flag evaluated? Decide whether the choice is made when a process starts, on every request or at a particular operation. One application needs consistent behaviour. If you assign a variant at process creation, store that assignment with the process instance; do not expect a later flag change to rewrite its history.
  2. What happens when the flag provider fails? Specify a default for each operation. Here, an uncertain configuration might disable automatic prefill while leaving manual submission available. “Always return false” is not a universal safety policy: assess security and availability consequences first.
  3. Who may disable the feature, and on what evidence? Name an owner, access rights, an alert threshold, a propagation mechanism, an acceptable reaction time and a way to prove that the old path is actually in use.

A six-field operational contract

Document the owner, blast radius (services, users and processes), fallback value, shutdown trigger (metric and threshold), propagation time and removal date. This is a proposed engineering practice, not a requirement imposed by the OpenFeature specification.

Distinguish a temporary release flag from a durable business setting. The release flag needs a retirement plan, including removal of the dead code path. A lasting product setting belongs to the product model and requires different governance. Every additional flag combination creates more system states to understand and test.

Five tests before calling the rollout controllable

  1. Disable the flag while a process is running. Verify the documented behaviour for in-flight and newly started applications.
  2. Disconnect the flag provider. Test errors, missing configuration and stale data rather than only the happy path.
  3. Measure propagation across instances and asynchronous workers. A successful click in a dashboard is not proof that the whole service has changed behaviour.
  4. Verify that an authorised operator can change the flag and an unauthorised actor cannot. Record who changed it, when and why.
  5. After rollout, remove the flag and unused branch of code, then run regression tests.

Specification versus design choice

OpenFeature specifies evaluation defaults, evaluation context and provider events such as PROVIDER_READY, PROVIDER_ERROR and PROVIDER_STALE. It does not prescribe a universal propagation deadline or business shutdown threshold. Those values must be chosen and measured for the actual implementation. Pete Hodgson's article distinguishes categories of toggles and explains the maintenance cost of keeping them around. The six-field contract above is our proposed way to turn those concerns into operational decisions.

Architect's question: if you must disable a feature at 14:00, what evidence at 14:05 proves that new operations no longer use it — and what happens to operations already in progress?

References