What are the reason to decouple databases on microservices?

Question

Here I my current findings on this subject, are these correct or is there an aspect missing?

There are two major principles for microservices:

• strong cohesion -> related code is gouped together, e.g. a class does on well defined job this is strong/hingh cohesion.
• loose coupling -> interconnect components in a system so that those components, depend on each other as less as practicable. Coupling refers to the degree of direct knowledge that one element has of another. So a change to one service should not require a change to another.

With a shared database (as in not decoupled) architecture both these principles are not covered. This due to the following facts:

• There is a fixed link between the users and the specific technology choice as well as to the actual database implementation.
• Businiess/application logic might be spread among multiple users.
• Shared information which needs to be edited can trigger a change of the behavior in multiple places.
• Due to the more monolithic architecture which goes with shared databases a failure can effect many serveries since they are all tied together, even a compelte system failure can happen due to the coupeling.

To avoid the above mentioned issues: decoupled databases can be used with microservices instead of shared databases. So each microservice should have its own database. This will also ease scaling of the system, provide much much more system availability, since "only" the one, really effected service will fail.

UPDATE: One other benefit of microservices would be that it can improve the flexibility and speed of development. Since correctly decomposed microservices, can be developed and deployed e independently and in parallel with the other services.

Answer 1

An important thing to mention is that microservices do not have to share the same schema, what is usually referred as Integration Database antipattern. But you can actually have different schemas in the same relational database as long as each microservice uses its own schema. What is important here is the potential ability to move some microservice data to a different physical server any time easily. It is simpler to deploy and backup 1 database than, let's say, seven or so, meaning this option is a good choice if you just at the very beginning of your project and don't want to spend too much time in managing bunch of databases. But you and your team have to be very disciplined to make sure that microservices are talking to data from their own schemas only.

Another thing is coupling. You can't make microservices completely isolated, meaning that they will still depend on each other to a certain degree. Just take a simple example of Product, Order, Shipment services. Those services have to be aware of each other, there is no way to make them completely separate. But you can make them temporally decoupled by using certain design strategies. When services are decoupled in this way, each one of them can be unavailable for some time (e.g. redeployment) with no effect on others.

Due to the more monolithic architecture which goes with shared databases a failure can affect many servers since they are all tied together, even a complete system failure can happen due to the coupling.

Temporal coupling will have the same effect even if your microservices are not sharing the same database. The simple rule to follow: don't call one microservice from another synchronously, use asynchronous events and commands instead.