Microservice architecture becomes a DeFacto standard for enterprise applications. Organizations are adopting Microservices at a larger pace because of the benefits offered by the Microservices.
This Article is part of our Microservice series. You can find the complete list of articles here.
This article provides an overview of the Database patterns in the Microservice ecosystem.
When choosing the database, please ensure you considered the volume of the data, the velocity at which it will be received, how it will be managed, security and resiliency requirements when choosing the database storage type
Below are the patterns that we are going to discuss in this post
- Database per Service
- Shared Database (Private Schema/tables)
Before delving into these patterns, let us understand why there is a need to have a separate database/schema instead of having one database that would hold all the data.
Having one database will pose constraints to team design choices as it impacts the other teams working on the same application. Instead of one team taking the decision, all the teams need to collaborate and make the decisions that involve the new/modifications to existing tables. This impacts team agility and productivity. Having a monolithic database will kill the majority of the advantages that we get with the Microservices. When you are using RDBMS, you face challenges from connection limits, concurrent transactions, and various other limits
By having a separate database/schema, you can enforce strict boundaries between each Microservice, make your service truly autonomous, scale independently, and promote loose coupling in the Microservice ecosystem.
Database per Service
Database per service ensures the data is private to the service, can be scaled the database as per the workloads, choose the right database storage type (relational, document, key-value and graph, etc.), and strict boundaries for the data managed by the service.
Any service that needs the data owned by the other microservice, should request via APIs or event-based communication.
Shared Database (Private Schema/tables)
Before proceeding further on this approach, this is considered as an anti-pattern.
This approach defines the schema/tables inside a database pertinent to the service and defines the logical boundaries. When the team implements the business functionality, they need to ensure they are not referring to the tables that are not part of their microservice. This approach looks reasonable in the short term but poses a lot of challenges in the long term that impacts the scaling, team agility, and deliverables.
