posts-go/posts/2022-10-26-reload-config.md

# Reload config

This serves as design draft of reload config system

```plantuml
@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