I'm thinking of things like config for nginx, Apache, Kubernetes, etc.
USER='{
"name": "joe",
"email":"joe@example.com"
}'Some go half-way, like HAProxy where it does spawn a new process but that process just binds with SO_REUSEPORT and signal old one to close the socket and finish all remaining connections. So you effectively get hitless reload, it's just that old process is the one finishing in-flight requests
It's a bit different for desktop apps, as restarting app every time you change some config options would be far bigger PITA than some server app.
Config files are better, but can lead to the mess described here and typically only give us crude axes for overriding.
It's time for us to embrace & tame the complexity. If you use a feature flag tool already, you know what it's like to target different values based on rules.
If I want to experiment with changing the http timeout for specific calls from a single service in a single region I should be able to roll that out.
It's time to expand our brains and bring this feature flag style thinking to the rest of our configuration.
...why ? how often you do it ? What actual app feature it fills ? Why would you throw permanent code at something that you need to do once or twice?
That kind of thing is FAR better served as customizable hooks (loadable .so/.dll, maybe even attached Lua interpreter) rather than bazillion random flags for everything and checks cluttering code.
httpClient.get("my/url", timeout: config.get("http.timeout"))
Where config is a library smart enough to do some rule evaluation over a live updated backing store to get the right value.
I'm not sure how .so/dll or lua is going to help here.