Most people say when building micro-services, that it's best to have separate databases for each of the microservices.E.g:User-microservice:DB - UseruserIdnameEtc...Review-microservice:DB - ReviewuserId | The user who posted the reviewReview-descriptionBut 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?
Micro-service database management?
database design;microservices;hibernate
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.