Separate DB Pattern
Conversion of monolithic application to microservices involves:
- Domain Driven Design to identify Bounded Context
- Assigning Bounded Context to Micorservices teams
- Team migrates the app to Microservice(s) by:
- Refactoring the app
- Refactoring the database
Each of the microservice owns the data model for their Bounded Context, which translates to each microservice owning, operating and managing their own database.
Database Refactoring
Breaking the database into multiple smaller database may be a challenge for databases that consist of:
- Large number of tables
- Stored procedures & triggers
The question is “Whether to continue with shared database or refactor?” answer depends on multiple factors specific to your organization:
- Time constraints
- Cost | Budget constraints
- Lack of skilled resources
- Risk
- Legacy technology
Objective
Achieve isolation of data within the same Database instance
- Each Microservice owns part of the data in the Database
- Each Microservice have direct access to ONLY its own data
How?
Use DB features to achieve MAXIMUM isolation between Microservices.
Isolate the database objects owned by each microservice e.g., use schema for isolating the DB objects owned by each microservice; use permissions to prevent direct access.
Transitioning to microservices
- Microservices create a services layer to access the database. This service layer is realized with a Strangler pattern. The idea is to replace the underlying database without the need for changing the microservice code.
- Each microservice team at their own pace move towards replacing the shared database platform with their own database
- Eventually each of the services are idependently managin their own database instance. At this stage microservice team has the freedom to use any appropriate database technology.
Downside of Separate Databases
- HIGHER cost of the Database for the solution
- Degraded Read Performance due to distribution of data
- Complexity in managing Transaction | Data integrity