...

Here's where it might make sense to pull in additional technologies that are better suited to these requirements.  See the Technologies section below.  Having a module that presents a common interface in front of these technologies which is used internally (i.e. intended to be called only by other modules, not directly by clients) is an option that provides flexibility and opens the door to many potential benefits.

...

• Migration of config data would need to be done on a per-module basis.  We could effectively deprecate mod-configuration and then at some later date retire/end-of-life it entirely.

JIRA

• Jira Legacy
  server FOLIO Issue TrackerSystem JIRA serverId 6ccf3fe401505d01-3301b853-368a3c2e-983e90f1-20c466b11a49ee9b165564fc key FOLIO-2583

Drawbacks

The "Externalized configuration" microservice pattern applies to deployment configuration (infrastructure and 3rd party services) only, not to business logic configuration. The business login configuration is completely independent of the deployment – it depends on the tenant or other properties.

Using mod-configuration for per-tenant business logic configuration violates the single responsibility principle (separation of concerns) where each service should be loosely coupled with other services and independently deployable. There is no benefit in moving them into a centralized configurations module.

Moving the per-tenant business logic configuration from mod-configuration into mod-*-storage but keeping a unified configuration interface has these drawbacks:

...

Only those configuration options (deployment configuration) should be unified/centralized that really require it (some advanced features of redis/vault/...).