Comment by chambers

Yes, feature flags are conflated with dynamic configs (or "remote configs"). The difference is subtle, hence why people are talking past each other.

Feature flags are gates for whether a piece of code runs; basically, an if-condition. Dynamic configs are a mechanism for changing runtime values without redeploying[1].

For example:

  # Feature flag — variant gate for rollout
  flag = SOME_CONSTANT_DEFINED_IN_MY_REPO  # remote config not needed
  if flag == 'open':
      render_new_checkout()
  elif flag == 'warning':
      render_warning_checkout()
  else:
      render_old_checkout()

  # Raw dynamic/remote config pulled — structured values for tuning behavior
  config = sdk.get_config(user, "checkout_settings")
  timeout_ms   = config.get("timeout_ms", 5000)
  max_items    = config.get("max_items", 50)
  allowed_tlds = config.get("allowed_tlds", [".com", ".org"])

In practice, feature flags use dynamic configs to handle the temporary lifecycle of a feature — aka, ship a new block of code, ramp its execution up to 100%, then delete the flag. Whereas dynamic configs don't use feature flags, they exist independently for semi-permanent operations like rate limits or business rules you'd expect a PM to change like the text copy on a marketing website.

As I've seen: the forcing function for the separation of the two concepts are experimentation platforms: when human-control of feature flags is shared with a new automated allocation system that manipulates dynamic config under the hood. That's how Statsig built their system and, in part, why they could sell for a billion. Whereas companies that ignored the difference, like LaunchDarkly, struggled outside of feature flags.

[1] https://docs.statsig.com/dynamic-config/overview https://engineering.atspotify.com/2020/10/29/spotifys-new-ex... https://blog.x.com/engineering/en_us/topics/infrastructure/2...