Why you should question the “database per service” pattern
Questioning experts is a good thing. I question the idea that in a single application, each service must have its database. I think the database per service concept has been quite damaging to software architecture for many years.
What problem is this pattern serving that cannot be solved by a modern relational database? Let’s examine:
Services must be loosely coupled so that they can be developed, deployed and scaled independently
https://microservices.io/patterns/data/database-per-service.html
I agree, but that is not an argument for overcomplicating your database.
Some business transactions must enforce invariants that span multiple services. For example, the Place Order use case must verify that a new Order will not exceed the customer’s credit limit. Other business transactions, must update data owned by multiple services.
https://microservices.io/patterns/data/database-per-service.html
Sure, but if your business logic involves transactions that span data owned by multiple services, perhaps the most reliable way to use transactions is to use RDBMS capabilities.
Some business transactions need to query data that is owned by multiple services. For example, the View Available Credit use must query the Customer to find the creditLimit and Orders to calculate the total amount of the open orders.
https://microservices.io/patterns/data/database-per-service.html
Again, if your business transactions need to query data owned by multiple services, you are complicating your life and productivity by separating a database per each service. I guarantee that even if you twist yourself into a pretzel at the onset of the project to avoid this, eventually, you will be pressured into supporting queries across services in a transactional fashion.
Some queries must join data that is owned by multiple services. For example, finding customers in a particular region and their recent orders requires a join between customers and orders.
https://microservices.io/patterns/data/database-per-service.html
To me, this reads as another argument for not splitting up the database.
Databases must sometimes be replicated and sharded in order to scale
https://microservices.io/patterns/data/database-per-service.html
A modern RDBMS can do that just fine.
Different services have different data storage requirements. For some services, a relational database is the best choice. Other services might need a NoSQL database such as MongoDB, which is good at storing complex, unstructured data, or Neo4J, which is designed to efficiently store and query graph data.
https://microservices.io/patterns/data/database-per-service.html
A modern RDBMS can do most of the above. As an architect, if you are sitting there in your silo creating a witch’s brew of a soup that involves multiple database technologies, perhaps you should re-examine both your sanity and your architecture.
I am not a fan of the database per service model. The correct pattern for the database model in a cloud-native environment is a data abstraction layer that hides the underlying database mechanics while allowing for transactions that span multiple services. The services should not know the architecture of the database, nor should they orchestrate their transactions.