2

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.

  • 1
    Your question presumes that those are the only two choices. – Robert Harvey Oct 10 '16 at 20:45
  • is multitenatcy what these 25 db implements? Or it's just matter of high availability? – Laiv Oct 10 '16 at 21:12
  • @Laiv Neither. To keep it brief, each one of those 25 databases corresponds to an instance of a small ERP package that the firm I work for has used for a very long time. There is not a suitable replacement for this package at the moment. We outgrew the initial scope of the ERP but continued to use an instance of it autonomously at each of our locations. Now we have some 3rd party software we need integrated in so we are looking to use a set of microservices to handle the data ETL, really. – Carson Oct 10 '16 at 21:21
  • 1
    I get the feeling that both approaches are legit. I have never thought in to allow clients to choose its db via headers (or whatever) but in this case makes sense because a single servicie does not know where the data is at. Or where it should be stored. – Laiv Oct 10 '16 at 22:31
  • What would be the SLA of the service? What's the expected concurrency? – Laiv Oct 10 '16 at 22:41
2

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.

  • Thanks, very in depth answer. I will mark it as accepted because you gave me many more things to consider that will help sway my decision. I guess we need to discuss some of the benefits and drawbacks of the individual design decisions a bit more. – Carson Oct 15 '16 at 14:46

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.