Design Patterns for Microservice Architecture – Database per Microservice

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).