Should I have a single Microservice Instance when there are several versions of the same database

Question

We have 25 instances of the same database facilitating different production plants in our organization. Basically, location X uses it's own copy of the database, location Y uses it's own copy, etc. The database facilitates the same functionality and persists the same type of data for each location, so a microservice that would sit on top of a database instance would to the same thing as the microservice on a different instance.

We eventually aggregate all of this information into a global data warehouse.

My question is, should we have one instance of the microservice per database and route to the correct microservice via another routing service, or should our clients just include information about what database they wish to use in request headers to a single microservice that can handle database routing internally?

The advantage to using a single service that handles routing internally is that instead of 25 instances we could have a couple instances (to manage load). Although, I am not entirely sure that having a couple load-balanced services is really an advantage.

This will be a REST based microservice.

Lastly, if there is a better alternative to these two choices and it seems within the scope of the question to mention the alternative, please do. These two choices are the paradigms I am considering at the moment.

Answer 1

I would say, it depends: There are multiple factors that may drive the decision in one or the other direction:

• Operating (e.g. hosting, monitoring) and maintaining (e.g. fixing, upgrading) multiple instances of the same service means more cost (e.g. hardware) and more work (either manual work or by implementing automation).

  Note that automation is usually a good thing, even if you have only a single or few instance(s).

• If you need to update your service and this update requires a new column in a table, can you do this all at the same time in all databases? Can you update all your clients at the same time?
• Do you have different SLAs or maintenance intervals per instance (e.g. because of time zones)?
• Reliability may increase when you have more instances: If one service goes down (e.g. because of load or bad requests), at least the other services should not be affected.
• If the client of each service instance is locally distributed (e.g. different cities) it can be desirable to place each database with its service at the clients location. So even if the inter-city network (e.g. internet connection) goes down, the client can work with its service autonomously.

• From an architectural point of view (as you already mentioned in your question):

  You move the routing from the service (all clients go to a singe service and this service needs to know the right database for each request) to the client (each client needs to know what service to go to but that service always talks to the same database).

  If you have a "static" 1:n relationship between database and client (i.e. a specific client always talks to the same database) I would tend to the "one service per database" solution.

• When having multiple instances of the service, searching for errors is often multiplied over all this instances (e.g. slight configuration differences between instances) but on the other hand it can be more localized (e.g. searching only a small log file instead of a giant one).

This are only some factors to consider (in no particular order) and there are probably more.

From only the points above my summary would be: If you need at least some of the flexibility and can afford the cost, go for "one service per database". But, as always, it depends.