0

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?

1 Answer 1

3

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.

8
  • Thanks! What is your opinion regarding configurations that spawn around multiple microservices or the ones that shared? they should be in a "system / general" configurations service? For example user context like chosen language / email notifications configurations, etc.
    – sborpo
    Nov 28, 2021 at 21:00
  • @sborpo I think it depends. Language seems like it could belong in a user service, but it depends on what else is in that service. It does feel like the preferred language is a property of the person behind the user account, much like an email address or mailing address. Email notification could be in a few different places. A "do not email" setting may be attributed with a user, while notification frequency and such may live somewhere else. I don't think there's a one-size-fits-all answer.
    – Thomas Owens
    Nov 28, 2021 at 22:33
  • I'd strongly disagree with this answer. Forcing the UI to have "business logic" is not a clever move and will almost always end up in trouble. Make your UI "dumb". Introduce a microservice thats centralises this functionality and fire events to tell your other microservices that they need to do something. Dec 12, 2021 at 23:36
  • @RobertPerry Where do I say that the UI should have business logic? Implying that is certainly not my intention, since I agree that the UI shouldn't have any kind of business logic.
    – Thomas Owens
    Dec 13, 2021 at 10:20
  • "I'd lean toward having the UI call the relevant APIs to allow users to view and change the configuration, as appropriate." Dec 13, 2021 at 10:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.