title: Why does each microservice get its own database?
body: <p>It seems that in the traditional microservice architecture, each service gets its own database with a different understanding of the data (described <a href="https://microservices.io/patterns/data/database-per-service.html" rel="noreferrer">here</a>). Sometimes it is considered permissible for databases to duplicate data. For instance, the "Users" service might know essentially everything about a user, whereas the "Posts" service might just store primary keys and usernames (so that the author of a post can have their name displayed, for instance). <a href="https://docs.microsoft.com/en-us/azure/architecture/microservices/design/data-considerations" rel="noreferrer">This page</a> talks about eventual consistency, sources of truth, and other related concepts when data is duplicated. I understand that microservice architectures sometimes include a shared database, but most places I look suggest that this is a rare strategy.</p>
  
  <p>As for why each service typically gets its own database, all I've seen so far is "so that each service owns its own resources," but I'm not convinced that a) the service layer in any way "owns" the persisted resources accessed through the database to begin with, or that b) services even need to own the resources they require rather than accessing necessary subsets of the master resources through a shared database.</p>
  
  <p>So what are some of the justifications that each service in a microservice architecture should get its own database?</p>