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

4
  • 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
    Commented Mar 27, 2015 at 6:41
  • 1
    did you check answers in that question?
    – gnat
    Commented Mar 27, 2015 at 7:04
  • 2
    @jtmarmon: do you think a service which handles a big central database is still a microservice?
    – Doc Brown
    Commented Mar 27, 2015 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
    Commented Mar 27, 2015 at 13:59

1 Answer 1

Reset to default
7

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).

4
  • 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
    Commented Mar 27, 2015 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
    Commented Mar 27, 2015 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
    Commented Mar 27, 2015 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
    Commented Mar 27, 2015 at 17:05

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