2

Hey Software Engineers

Currently we basically have a what I would call "modular monolith".

A diagram would likely look something like this:

enter image description here

What we want to do in the future is being able to deploy each module independently and move to a microservice environment where every module has its own database.

We have a table that is called SysParams that stores:

  • system parameters that are used by all modules (so common sys params)
  • system parameters that are only used by the individual modules

The individual system parameters per module can be moved to the modules database, but the common sys params we still want in a dedicated table (without duplicating it in every module).

What would be a good way to achieve this?

I thought about having another "master data service" that provides the common sys params. But what I don't like in this solution is, that I need an additional http call every time. I also thought about calling the "master data service" once in the startup and caching the result inmemory in the modules but I'm also not sure about this approach.

Thank you for your insights on this issue :-)

4
  • What are some examples of common system parameters?
    – user253751
    Oct 28, 2021 at 16:52
  • @user253751 for example username / passwords to other services in the organization that multiple modules use (we want to have them in one place so if a password changes for example, it has to be updated only once)
    – xeraphim
    Oct 29, 2021 at 5:56
  • @user253751 as an addition: the data in the common system parameters are configurations and don't change often
    – xeraphim
    Oct 29, 2021 at 6:05
  • 1
    Consider using a devops/deployment tool (e.g. OctopusDeploy, GitlabCI, Jenkins, etc) to manage this configuration as well as the rest of your deployment centrally, to allow the tool to write copies of that configuration into each service/container/VM/environment or wherever else it's needed. (So you may need 100s of copies of the same configuration, but if it changes you'll only ever update it in the deployment tool's own data store use that to publish updates). For anything sensitive consider looking into a Secrets Vault (if the deployment tool has nothing built-in). Nov 5, 2021 at 14:11

1 Answer 1

2

If the parameters change through "ops" (i.e. not as part of the service), I would remove it from database completely, make it "normal" environment variables for the service.

Then make those settings a part of the versioned infrastructure code. For example a k8s "SealedSecret", checked into git.

This way you simplify the whole thing, remove the central dependency, add versioning, and still have one central place to manage it for all.

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.