This serves as design draft of reload config system
@startuml Reload config
+
+skinparam defaultFontName Iosevka Term SS08
+
+participant admin
+participant other_service
+participant config_service
+participant storage
+
+== Admin handle ==
+
+admin -> config_service: set/update/delete config
+
+config_service -> storage: set/update/delete config
+
+== Other service handle ==
+
+other_service -> other_service: init service
+
+activate other_service
+
+other_service -> storage: make connection
+
+loop
+
+ other_service -> storage: listen on config change
+
+ other_service -> other_service: save config to memory
+
+end
+
+deactivate other_service
+
+other_service -> other_service: do business
+
+activate other_service
+
+other_service -> other_service: get config
+
+other_service -> other_service: do other business
+
+deactivate other_service
+
+@enduml
+Config storage can be any key value storage or database like etcd, Consul, mySQL, ...
If storage is key value storage, maybe there is API to listen on config change.
Otherwise we should create a loop to get all config from storage for some interval, for example each 5 minute.
Each other_service need to get config from its memory, not hit storage.
So there is some delay between upstream config (config in storage) and downstream config (config in other_service), but maybe we can forgive that delay (???).
Pros:
Config can be dynamic, service does not need to restart to apply new config.
Each service only keep 1 connection to storage to listen to config change, not hit storage for each request.
Cons:
storage.storage failure.