~

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:

• Each service has 1 more dependency, aka storage.
• Need to handle fallback config, incase storage failure.
• Delay between upstream/downstream config