Explain Database per Service in Microservices

7 / 12

data

Database per Service

Each service owns its data and database; other services only touch it through the owner's API or events.

Database-per-service is the data-ownership rule that makes microservices actually independent: each service has its own private database, and no other service is allowed to read or write it directly — they must go through the owning service's API or consume events it publishes. Without this rule, a shared database silently recouples everything; a schema change for one service can break others, teams contend over the same tables, and the "services" become a distributed monolith that cannot be deployed or scaled independently.

Separate bank accounts per family member: you can't reach into someone else's account directly — you ask them, and each person manages their own money their own way.

Key Concepts

Enforcing private data stores gives each service true autonomy: it can choose the database technology that fits its workload (relational here, document or key-value there — polyglot persistence), evolve its schema on its own schedule, and scale its storage independently. The cost is that data is now scattered across many databases, which makes two things genuinely hard. First, queries that need data from several services can no longer be a simple SQL join; you must compose the data via API calls, maintain a read-optimised view, or use the CQRS pattern to build a denormalised query model fed by events. Second, a business operation that spans services can no longer be one ACID transaction across tables, because there is no shared database to wrap them — which is exactly the problem the Saga pattern exists to solve, coordinating local transactions with compensating actions instead of a distributed commit.

The trade-off interviewers want articulated is autonomy versus convenience: you give up easy cross-service joins and simple distributed transactions in exchange for services that can be developed, deployed, and scaled independently and fail in isolation. Keeping data consistent across services then shifts to asynchronous, eventually-consistent techniques — domain events, sagas, and CQRS read models — and accepting eventual consistency where you previously had strong consistency is part of the bargain. The boundary discipline is the whole point: cross a service's data boundary only through its published contract, never its tables.