Micro-service database management?

Question

Most people say when building micro-services, that it's best to have separate databases for each of the microservices.

E.g:

User-microservice:

1. DB - User
   • userId
   • name
   • Etc...

Review-microservice:

1. DB - Review
   • userId | The user who posted the review
   • Review-description

But I've been thinking, is it best to have a ORM which builds the database tables, adds the foreign keys, primary keys, indexes, etc...And then have each of the micro-services use the database which was built by the ORM.

This would enforce constraints, which would hopefully prevent the number of bugs/issues you come across later on, It'd also help with query performance (joins, indexes, etc...).

Here's what I'm thinking:

We currently have a monolithic API which contains a lot of code (years of it) and a complex DB schema design, I'm thinking of building micro-services in Java and using hibernate to create models based on the django schema.

Is this a good approach?

Answer 1

Microservices do come with a performance penalty for some cases, which is offset by better scalability. It may seem like a paradox, but sometimes you need to make an individual operation slower in order to make it possible for the system to scale better. In your case, better scalability means you can't handle complex state changes between many tables in a single SQL statement. So, it's up to you to decide which is more important: scalability or single-operation performance. Microservices are no silver bullet and they make sense in some case and not in others.

One thing I would advise you to not do, however, is the solution of writing "microservices" operating on a shared database. This would give you the worst of both worlds: shared database limits your scalability so you don't get one of the main benefits microservices normally offer while having your code split into multiple separate applications adds all of the coding, deployment and maintenance overhead of the microservice world. Note that in such a situation your applications all depend on the same database so any change to the DB is much harder to implement and deploy than in a monolithic application. So you get most of the downsides of both worlds.

Answer 2

The reason why you often have a database for each micro-service, is in order to separate each part of the system. If you store everything in one database, you will (as mentioned by Michal Kosmulski) lose some scalability. But more importantly, each micro-service might be better off with some other form of storage. Some of your micro-services might be best off with a relational database - others might be better with some NoSQL database.

Having a separate data-storage for each micro-service, means you can choose the best solution for each service. You do not have to try to fit everything down into one big RDBMS.

Another advantage is that no other service (perhaps coded and maintained by another team) has the "urge" to look directly into your database, instead of calling your service - they simply do not have access to it. So they HAVE to use your service, meaning you can directly control every call and data change.