Microservice & Database Architecture

Let’s imagine you are developing an online store application using the Microservice architecture pattern. Most services need to persist data in some kind of database. For example, the Order Service stores information about orders and the Customer Service stores information about customers.

So what is the Problems With Monolithic Database Design?

1- The traditional design of having a Monolithic Database for multiple services creates a tight coupling and inability to deploy your service changes independently.

2- It is difficult to scale individual services with this design since you only have the option to scale out the entire monolithic database.

3- Most of the times you have a relational store as your monolith database. This constraints all your services to use a relational database. However, there will be scenarios where a No-SQL datastore might be a better fit for your services and hence you don’t want to be tightly coupled to a centralized datastore.

So How to Handle Your data in a Microservice Architecture?

Each microservice should have its own database and should contain data relevant to that microservice itself. This will allow you to deploy individual services independently.

Keep each microservice’s persistent data private to that service and accessible only via its API. A service’s transactions only involve its database.

Microservices should follow Domain Driven Design and have bounded contexts.

There are a few different ways to keep a service’s persistent data private. You do not need to provision a database server for each service. For example, if you are using a relational database then the options are:

• Private-tables-per-service — each service owns a set of tables that must only be accessed by that service
• Schema-per-service — each service has a database schema that’s private to that service
• Database-server-per-service — each service has it’s own database server.

Private-tables-per-service and schema-per-service have the lowest overhead. Using a schema per service is appealing since it makes ownership clearer. Some high throughput services might need their own database server.

It is a good idea to create barriers that enforce this modularity.

Using a database per service has the following drawbacks:

• Implementing business transactions that span multiple services is not straightforward. Distributed transactions are best avoided because of the CAP theorem. Moreover, many modern (NoSQL) databases don’t support them.
• Implementing queries that join data that is now in multiple databases is challenging.
• Complexity of managing multiple SQL and NoSQL databases.

There are various patterns/solutions for implementing transactions and queries that span services:

• Implementing transactions that span services — use the Saga pattern.

Thanks for reading this article.