Should Configurations Be Split To Different Microservices?

Question

As part of a microservice-based system design, I'm struggling to decide where system configurations should reside in terms of domain ownership.

For example, let's assume I'm designing a "store system" where for simplicity I want to discuss the following domains that have today 1 microservice for:

1. Orders
2. Inventory

Now I have a global setting UI menu that via this menu we are managing configurations. Example for 2 configurations:

1. Orders - "remove unapproved orders after X days"
2. Inventory - "make automatic inventory orders for critical components"

What is the best place to manage the configurations?

1. A microservice that manages System Configurations and the Orders, Inventory microservices will read from it to apply their logic. There will be a set of "settings" APIs for this service that will be exposed to the user.
2. The configurations should be managed in the orders and inventory microservices respectively and the UI should call the relevant APIs of these microservices.

What is the better approach here? In "Configurations" should be considered as a domain of its own? or the configurations should reside in each one of the services?

Answer 1

I'd lean toward having the UI call the relevant APIs to allow users to view and change the configuration, as appropriate.

The biggest reason is that a new microservice to manage configuration would likely break one of the key characteristics of a microservice, which is that they are independently deployable. You may be able to technically make them independent by having default values outside of the configuration service, but you would now need to deploy at least two services to fully realize the ability to change rules.

The use of a configuration service also seems to stretch the idea of organizing services around domain contexts, since configurable rules for multiple domain contexts would live in one service.

UI elements calling multiple services is already necessary quite often. In my experience, UI screens often need to collect and display data from multiple services. Having the front-end elements reach out to services for configuration information seems just as reasonable as having the UI reach out to multiple services to get the order and inventory business data.