18

I am planning to use the Microservices architecture for the implementation of our website. I wanted to know if it is right to share databases between services or if it is preferable to have a separate database for each service. In this regard, can I consider having one common database for all services or does it violate the very essence of Microservice architecture ?

user2288991
  • 241
  • 1
  • 2
  • 4

2 Answers2

43

Microservices offers decoupling. You must break down your application into independent domains. Each domain can have a DB. In case other MS needs to access data owned by some other microservices, they have to communicate over the network.

In case you feel that there are too many dependent services and the network calls would be too much, then you can define a domain, clustering the dependent services together.

For instance -- Suppose I have an online Test evaluation Service where a manager of a company can post tests and he can view results of all the employees in his department.

My Microservices for this scenario would be:

Initial Design

  1. User Service: For login and user information.
  2. Test Service: Service to evaluate tests.
  3. Employee: Handles employee details
  4. Company: Handles organization CRUD
  5. Department: Handles department CRUD

After breaking it down, seems like employee, Organization and Department service would be making too much network/API calls as they are tightly dependent on each other. So it's better to cluster them.

Updated design

  1. User Service : For login and user information.
  2. Test Service : Service to evaluate tests
  3. Organization : Handles Company, Employee and Department related operations.

Each service could have it's own DB and it's independently deployable. User and Test Service can use mongoDB or any NoSql DB and Organization service can use RDBMS.

Hope this helps.

Stefano Munarini
  • 2,711
  • 2
  • 22
  • 26
Nitish Bhardwaj
  • 1,113
  • 12
  • 29
18

If you share the same database then you loose two of the most important advantages of microservices: strong cohesion and loose coupling (page 25).

You can share the same database if you don't share the tables in it. For example, microservice1 uses table1_1 and table_1_2 and microservice2 uses table2_1 and table2_2. When I say uses I mean read and write. One microservice don't read and don't write on the other's tables.

Constantin Galbenu
  • 16,951
  • 3
  • 38
  • 54
  • 2
    Thanks for the answer. But in my application, there is a case where one of the services makes use of data from a couple other services. In such a case, am I not risking too many API calls between services and from client to different services ? – user2288991 Apr 15 '17 at 15:03
  • 7
    Microservices communicate only using the network – Constantin Galbenu Apr 15 '17 at 15:06
  • 2
    You may want to look at your design, find the bounded context so you have nicely carved out verticals, that way you should not need to cross services boundaries to do data updates (state changes), data reads are less of a concern... – Sean Farmar Apr 20 '17 at 15:41
  • you could use a message broker for sharing state, and each microservice saves this state to its own (maybe service local) database (or a cache). – sschrass Aug 25 '18 at 15:19
  • @ConstantinGalbenu What if I need some data? For example for computing certain statistics for scheduled weekly emails – scarface Oct 08 '19 at 14:56
  • @scarface then you copy it asynchronously to a local cache table. i.e. in a cron job – Constantin Galbenu Oct 10 '19 at 12:20
  • I don't agree with the copy pattern -- **almost** ever, but do agree w/ the the idea that microservices only communicate using the network -- if you need data from a microservice I'd recommend creating an endpoint to serve that -- instead of using the DB API directly; this will be managed as part of the endpoint spec and as such the team managing the microservice will know & own the db operations (you won't have to worry about it breaking) whereas if you use the DB API the owning team wont have insights into how you're using it and my introduce code-breaking changes – Schalton Oct 23 '20 at 00:27
  • To @ConstantinGalbenu 's point -- that's for tables, not DBs The only exception I can think of is a single table design in a no sql db where you may have multiple microservices reading & writing from the same table In this case; there are often performance gains that warrant the extra collaboration/shared ownership -- IMO I'd make a 3rd party or composite team the owner of the DB in that case -- so any proposed changes are managed by the stakeholders and not a dev team who is unaware of competing requirements – Schalton Oct 23 '20 at 00:31