Master data

Handling master data is more about your personal choice and system-specific requirements. If you see that the master data is not going to change for ages and occupies an insignificant amount of records, you are better off with the configuration files or even code enumerations.

This requires someone to push out the configuration files once in a while when the changes do happen. However, this still leaves gap for future. As the rest of the system would depend on this one module, it will be responsible for these updates. If this module does not behave correctly, other parts of the system relying on it could also be impacted negatively.

Another option could be to wrap up master data in a separate service altogether. Having the master data delivered through a service would have the advantage of the services knowing the change instantly and understanding the capability to consume it as well.

The process of requesting this service might not be much different from the process of reading configuration files when required. It might be slower for once, but then it is to be done only as many times as necessary.

Moreover, you could also support different sets of master data itself. It would be fairly easy to maintain product sets that can differ every year. With the microservice-architecture style, it is always a good idea to be independent of any kind of outside reliance in future.