Once a company replaces the large monolithic system with many smaller microservices, the most important decision it faces is regarding the Database. In a monolithic architecture, a large, central database is used. Many architects favor keeping the database as it is, even when they move to microservice architecture. While it gives some short-term benefit, it is an anti-pattern, especially in a large-scale system, as the microservices will be tightly coupled in the database layer. The whole object of moving to microservice will fail (e.g., team empowerment, independent development).
A better approach is to provide every Microservice its own Data store, so that there is no strong-coupling between services in the database layer. Here I am using the term database to show a logical separation of data, i.e., the Microservices can share the same physical database, but they should use separate Schema/collection/table. It will also ensure that the Microservices are correctly segregated according to the Domain-Driven-Design.
Pros
- Complete ownership of Data to a Service.
- Loose coupling among teams developing the services.
Cons
- Sharing data among services becomes challenging.
- Giving application-wide ACID transactional guarantee becomes a lot harder.
- Decomposing the Monolith database to smaller parts need careful design and is a challenging task.
When to use Database per Microservice
- In large-scale enterprise applications.
- When the team needs complete ownership of their Microservices for development scaling and development velocity.
When not to use Database per Microservice
- In small-scale applications.
- If one team develops all the Microservices.
Enabling Technology Examples
All SQL, NoSQL databases offer logical separation of data (e.g., separate tables, collections, schemas, databases).
