[akoboldfrying]

But you have this same issue if you store those 3 bits of state as "app config" instead of as "feature flags".

I think it's useful to distinguish between kinds of feature flags -- "traditional" feature flags for safe rollout of new features (these should be removed on a strict timeline, to preserve maintainability) vs. "config"-type flags that are designed to remain indefinitely and optionally be configurable by certain end users. But I don't yet see a reason why the actual mechanism for these two things (namely, a function with a descriptive name that can be called to quickly return a small datum that is periodically refreshed from somewhere in the background) can't be the same.

[jeremyjh]

Yes people are speaking past each other to some extent here; but if we're going to talk about "Feature Flags" we aren't talking about using a flag service for "normal" configuration - whatever that means. But what, exactly - does that mean? I normally consider things like the following configuration:

API Host Names, client Ids, secrets, Database connection strings Other runtime settings like pool sizes, replica counts etc

Most of those things are secrets, or they are specific scalar values closely tied to the application runtime, that often need to be known at startup. Are people putting those in a "feature flag" service? If not, what is a good example?

My comment only applies to "configuration" that alters behavior, usually in binary off/on manner. Which is what I'd call a "Feature Flag".