What is the best way to store constant field in microservice architecture?

What is the best way to store constant field in microservice architecture?

Many servers use the same constants, it is necessary to organize a centralized changing them. What is the best way to store constant parameters in microservice architecture.
For example, we store static final int MAX_PEOPLE_COUNT = 100; This field use different microservices. If we change this value, all microservices should see it.
It would be great to have also the versioning of the parameter values.


Solution 1:

In case you are in the Spring ecosystem, the best way would be to use the Spring Cloud Config Server. You can readily and easily get the steps to setup a config server in the Spring Cloud Config Server guide and here too. The documentation is pretty much straightforward.

You can even use Zookeeper as a centralized config service with Spring Cloud. More details on that in this article.

Solution 2:

There are many solutions to store cross-micro-service configuration. Starting with all commons database. We specifically using consul by HashiCorp in order to store our cross-micro-service configurations.

Solution 3:

Extending the Argument by @Madhu Bhat, in my opinion also the best way is to use Spring Cloud Config Server (getting started)

Now specific to your use-case that couple of microservices share some common configurable value (I have intentionally changed the word from CONSTANT to CONFIGURABLE, as by definition constant is not something that is supposed to be changed), best practice to use configuration files in spring is as follows:

Suppose you have 3 microservices in your eco-system (hypothetical scenario)

  • billing-service
  • cart-service
  • product-service

As a best practice, you should maintain configuration file at various levels –

  • microservice + environment specific config file e.g. billing-dev.properties or billing-test.properties
    This property file would contain properties that are specific to a particular environment for a particular service. Billing service might have certain properties that are different for your dev environment and different for a test environment. You can have as many properties/configuration files as your environments.

  • Microservice level – properties common for all the environments for particular microservices e.g. billing.properties

  • application.properties – this property file contains those properties that are common for all the microservices or multiple microservices (your use-case) e.g. billing and product service both need some configurable property.

Property/configuration resolution:

From microservice prospective (say billing service), any property would be first searched in the first-mentioned property file (billing-test.properties or billing-dev.properties) according to what environment you have specified on the service startup by configuration by property (see here in detail)


If the desired property is not found in environment specific property then fallback configuration file to be searched would be second-mentioned file generic service configuration file for all environments (billing.properties).

If property is not found in above mentioned two files that it would be resolved by application.yml file