...

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.

...

JIRA

• Jira Legacy
  server System JiraJIRA serverId 01505d01-b853-3c2e-90f1-ee9b165564fc 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:

• Client needs to pass a parameter with the module name, this adds complexity.
• The configuration must fit into the 8 fields (mod-configuration API):  "module", "configName", "code", "description", "default", "enabled", "value", "userId"
• The API documentation cannot explain the configuration options: mod-configuration API

These drawbacks can be avoided by using module specific configuration APIs. Example: https://s3.amazonaws.com/foliodocs/api/mod-orders-storage/configuration.html

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