Probably the leading persistence-related change introduced by the microservices architecture is strong encouragement to not share data stores between services. This means that each logical service owns and manages its database (if it requires a database at all) and ideally no other service can access the data in a way that is different from a service API call.

It is out of this book's scope to explain all the reasons for such separation, but the most important ones are as follows:

• The ability to evolve different services separately, without tight coupling on a database schema
• The potential for more precise resource management
• The chance of horizontal scalability
• The possibility to use the best fit persistence implementation

Consider the following diagram:

At the physical level, storage separation can be implemented in a few different ways. The simplest way is to have one database server and one database for all services, but to divide them using separate schemas (schema per microservice). Such a configuration can be easily implemented, requires a minimal amount of server resources, and does not require much administration in production, so it is pretty attractive in the first stages of application development. Data separation could be enforced with the database access control rules. Such an approach is easy to implement, but at the same time, it is easy to break. As data is stored in the same database, it is sometimes tempting for developers to write a single query that may retrieve or update data belonging to more than one service. It is also easier to compromise the security of the whole system by compromising only one service. The following diagram shows the design of the mentioned system:

Services may share a single database server but have different databases with different access credentials. Such an approach improves data separation as it is much harder to write a single query capable of accessing external data. However, this also complicates backup routines a little. The following diagram depicts this:

Each service may have its database server. Such an approach requires a lot more administration but provides a good starting point for fine-grained tuning of the database server to meet the needs of the concrete service. Also, in this case, it is possible to only vertically and horizontally scale the databases that require such scalability. The following diagram shows this:

When implementing a software system, all of the previously mentioned techniques could easily be used simultaneously in different proportions depending on the actual demands of the system. The following schema shows the design of such a system:

Furthermore, it is possible to have different database server instances, and we can now use different database engines together (SQL and NoSQL) to achieve the best results. This approach is called polyglot persistence.