Database-Per-Service Pattern

In a monolithic application, it's common for different parts of the system to share a single database. The order management module, payment module, inventory module, and user management module might all read and write tables in the same database.

This approach is simple and convenient. If the order module needs customer information, it can directly query the users table. If it needs payment details, it can join the orders and payments tables.

However, when we move from a monolithic architecture to microservices, this shared database becomes a problem. Microservices are supposed to be independently developed, deployed, and scaled. But if multiple services depend on the same database schema, they remain tightly coupled, even though their application code runs in separate processes.

The Database-Per-Service Pattern solves this problem by giving each microservice ownership of its own data. Let's understand how it works, why it matters, and what trade-offs it introduces.