I think the confusion here is that traditionally a feature flag is part of the source code, or potentially deployment configuration. Not something that should b

I think the confusion here is that traditionally a feature flag is part of the source code, or potentially deployment configuration. Not something that should be modified during runtime of production code, but only during deployments/releases. It seems that the modern interpretation is much more fluid, where a feature flag can be toggled on and off during runtime over multiple services. It seems logical that you would then want a "command and control" API that flips these things on a larger scale. However, to me this still sounds very strange. If you have 5k feature flags, do you really have any idea of what is running at all, at any time, anyway? What if you get a bug ticket from last week? Is there such a thing as a "deployment" if the code you execute is dependent on 5k bits that can be flipped and alter execution at any time? If you really need this much runtime configuration shouldn't it be part of some admin workflow that is just inherent to your application? Why would you even risk synchronizing another piece of state over a distributed system that alters the code? Wouldn't you want this stuff to just be part of your data model? Seems its no longer about feature flags, but about having a global table of bits you can abuse from any and all elements of your architecture, as a shortcut to actual good data design.