What is the database-per-service pattern and why is shared database an anti-pattern?
Learn the database-per-service pattern, why a shared database is an anti-pattern, and how sagas and events handle cross-service data, with interview answers.
Expected Interview Answer
The database-per-service pattern means each microservice owns its own private database, and no other service is allowed to read or write it directly; the only way to access that data is through the owning service's API.
This keeps each service loosely coupled and independently deployable, because a service can change its schema without breaking anyone else. A shared database is an anti-pattern because when many services read and write the same tables, they become tightly coupled through the schema: one team's migration can break others, the database becomes a scaling bottleneck and single point of failure, and no service truly owns its data. The trade-off of database-per-service is that cross-service data needs API calls or events, and transactions spanning services require patterns like sagas instead of a single ACID transaction.
- Loose coupling between services
- Independent schema changes and deployments
- Each team owns its data and technology choice
- Failures and load are isolated per service
- Clear service boundaries enforced through APIs
AI Mentor Explanation
Database-per-service is like each team keeping its own private notebook of tactics and fitness data. No rival or teammate rifles through another team's notebook directly; they only get information through official briefings. A shared database is like every team scribbling in one communal notebook, where one team erasing a page instantly disrupts everyone else relying on it.
Step-by-Step Explanation
Step 1
Assign data ownership
Give each service its own database and make it the sole owner of that data.
Step 2
Block direct access
Forbid other services from touching the tables; all access goes through the owner's API.
Step 3
Expose data via APIs or events
Publish the data other services need through synchronous APIs or asynchronous events.
Step 4
Handle cross-service reads
Use API composition or maintain read models to answer queries that span services.
Step 5
Manage distributed transactions
Replace multi-service ACID transactions with sagas and eventual consistency.
What Interviewer Expects
- Definition emphasizing private, service-owned data
- Why a shared database creates tight coupling
- Awareness of scaling and single-point-of-failure problems
- Knowledge of the trade-offs: sagas, eventual consistency, data duplication
- How cross-service queries are handled without shared tables
Common Mistakes
- Letting services reach into each other's tables directly
- Assuming distributed transactions work like a single ACID transaction
- Ignoring eventual consistency and data duplication trade-offs
- Thinking database-per-service always means separate physical servers rather than logical isolation
Best Answer (HR Friendly)
“Database-per-service means each small service keeps its own private data and lets others in only through its API. Sharing one database across many services is risky because a single change can break everyone and no one clearly owns the data.”
Code Example
order-service --> orders_db (private)
payment-service --> payments_db (private)
// Not allowed: payment-service reading orders_db directly
// Allowed: payment-service calls order-service API
GET /orders/42 (via order-service only)Follow-up Questions
- What is the saga pattern and when do you need it?
- How do you run a query that spans multiple services' data?
- What is eventual consistency and why does this pattern require it?
- What is CQRS and how does it relate to database-per-service?
- Can multiple services share one database server but separate schemas?
MCQ Practice
1. In the database-per-service pattern, how do other services access a service's data?
Only the owning service touches its database; others must go through its API or events.
2. Why is a shared database considered an anti-pattern in microservices?
Shared tables couple services so one schema change can break many, hurting independence and scaling.
3. What replaces a single ACID transaction across multiple services?
The saga pattern coordinates a sequence of local transactions with compensating actions for failures.
Flash Cards
What is database-per-service? — Each microservice owns its private database, accessed only through that service's API.
Why avoid a shared database? — It couples services through the schema, so one change can break many and it becomes a bottleneck.
How do cross-service transactions work? — Via the saga pattern with local transactions and compensating actions, not a single ACID transaction.
How are cross-service queries answered? — Through API composition or maintained read models, since you cannot join across private databases.
Continue Learning
Related Interview Questions
What is the CQRS pattern and when should you use it?
medium
A service needs data owned by another service on almost every request. Do you call it, cache it, or copy it into a read model?
hard
What is the difference between a monolithic and a microservices architecture?
medium
What is an API gateway and what role does it play in microservices?
medium