title: What are the reason to decouple databases on microservices?
body: <p>Here I my current findings on this subject, are these correct or is there an aspect missing?</p>
  
  <p>There are two major principles for microservices: </p>
  
  <ul>
  <li><strong>strong cohesion</strong> -> related code is gouped together, e.g. a class does on well defined job this is strong/hingh cohesion. </li>
  <li><strong>loose coupling</strong> -> 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.</li>
  </ul>
  
  <p>With a shared database (as in not decoupled) architecture both these principles are not covered. This due to the following facts:</p>
  
  <ul>
  <li>There is a fixed link between the users and the specific technology
  choice as well as to the actual database implementation.</li>
  <li>Businiess/application logic might be spread among multiple users.</li>
  <li>Shared information which needs to be edited can trigger a change of
  the behavior in multiple places.</li>
  <li>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.</li>
  </ul>
  
  <p>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. </p>
  
  <p><strong>UPDATE</strong>: 
  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.</p>