10

We're rebuilding a system in a microservice archiecture. I know the standard practice for SOA is to have each individual service responsible for its own database.

However, does it make sense to have one 'database' service responsible for handling a monolithic database (i.e. holding users, orders, inventory, etc in one db)? Is this something that's considered reasonable?

Or is the expectation that users, orders, inventory will all have their own separate databases and according services? If that's the case, how do I handle it when I want to do a simple relational query like ordering a list of inventory by how many orders we've had for each item?

Edit: not duplicate. to clarify (from comments): I understand that it's bad to share databases among multiple microservices. my question is whether having a big central database managed by a single microservice is a bad idea, or if it's critical that the internal system's data be decoupled itself

marked as duplicate by Doc Brown, durron597, GlenH7, user40980, gnat Apr 1 '15 at 16:09

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • I understand that it's bad to share databases among multiple microservices. my question is whether having a big central database managed by a single microservice is a bad idea, or if it's critical that the internal system's data be decoupled itself – jtmarmon Mar 27 '15 at 6:41
  • 1
    did you check answers in that question? – gnat Mar 27 '15 at 7:04
  • 2
    @jtmarmon: do you think a service which handles a big central database is still a microservice? – Doc Brown Mar 27 '15 at 8:28
  • yep i see now in the answers that they should be decoupled, but the second part of my question is how to do that. I don't understand how you can decouple major parts of your database and not be limited in your relational queries. wouldn't this essentially impose the same limitation is a nosql database like mongodb where your queries must operate in a single collection – jtmarmon Mar 27 '15 at 13:59
6

However, does it make sense to have one 'database' service responsible for handling a monolithic database (i.e. holding users, orders, inventory, etc in one db)? Is this something that's considered reasonable?

I think this is a mistake to make a service (or whatever) in SOA or any other architecture responsible for a database or a part of database or a table or whatever database part you can imagine.

Service is about fulfilling a user (or may be other service's) request. Database interaction is only a secondary to that. Microservice servers a group of requests, not a group of tables.

It is my understanding, that services are usually designed to use a dedicated database just to ensure maximum decoupling. This way service data is physically separated from the data of another service. Also this decision allows you to easily move service to a new platform (just move service app server + database into another machine).

You can use single database if you will find other means of keeping your services decoupled and if you will not be too troubled with moving a specific part of your database to, say, another machine (figuring out which part of database belongs to which service is sometimes not easy).

  • thanks for your answer. I don't quite understand, however, how you can have dedicated services for fulfilling requests without sharing data, which is my main confusion. it is quite a common example (i believe) to have an orders and an inventory microservice, so how, in that case, could you service a request that requires aggregation (like sorting inventory by how many orders there are) without giving the inventory service access to the orders database – jtmarmon Mar 27 '15 at 14:35
  • @jtmarmon Only service, responsible for data should access it. Well, in most cases. If two services share data... well, they are both responsible. And when many people are responsible for something, eventually, it turns out that none are ;) In your case aggregated request can be served by aggregation service, which requests data from other services. Or one service queries data from another. But ideally this situation should not arise. Services should be as isolated as possible. – Vladislav Rastrusny Mar 27 '15 at 16:52
  • so it sounds like there's no reason to use a relational database in a microservice infrastructure because you have to do your own joins. this is really not making sense to me – jtmarmon Mar 27 '15 at 17:01
  • @jtmarmon I do not think so. If you really need joins too often it means, that you incorrectly split your domain into subdomains (meaning you need to redesign your services). I think you should open another question, describing your problem domain in detail (what things do you have and what do you want to do with them) and ask about most optimal way to split them it into microservices. Ping me with a link to it ;) I will do my best to help you. – Vladislav Rastrusny Mar 27 '15 at 17:05

Not the answer you're looking for? Browse other questions tagged or ask your own question.