What is the Database-per-Service Pattern in Microservices?
Learn the database-per-service microservices pattern, why direct cross-service queries are forbidden, and its trade-offs.
Expected Interview Answer
The database-per-service pattern means each microservice owns its own private database that no other service is allowed to access directly, so services communicate only through APIs or events, never through shared tables.
This keeps each service's data model and schema fully internal, letting teams change a table's structure without coordinating with every other service that might have been querying it directly. It also lets each service pick the database technology that best fits its workload — one service might use a relational database, another a document store. The trade-off is that operations spanning multiple services can no longer use a single SQL join or transaction, so patterns like API composition, CQRS, or the saga pattern are needed to keep data consistent and to answer queries that span service boundaries.
- Services can evolve their schema independently
- Each service can choose the database technology that fits its data
- Failures and load in one service's database do not directly cascade to others
- Enforces clear ownership boundaries around data
AI Mentor Explanation
Imagine each department of a cricket board — ticketing, player registration, and merchandise — keeping its own private records rather than sharing one giant ledger. Ticketing never reaches into the player registration file directly; if it needs a player's name for a meet-and-greet event, it asks the registration department through a formal request. Database-per-service works the same way: each microservice owns its data exclusively, and other services must ask through an API rather than querying its tables directly.
Step-by-Step Explanation
Step 1
Assign one database per service
Each microservice provisions and owns its own database instance or schema, isolated from others.
Step 2
Forbid direct cross-service access
No service is allowed to query another service's tables directly, even if technically reachable.
Step 3
Expose data via API or events
A service that needs another service's data calls its API or subscribes to events it publishes.
Step 4
Handle cross-service consistency
Use patterns like sagas, CQRS, or API composition to keep data consistent and answer cross-service queries.
What Interviewer Expects
- Clear statement that each service owns a private, exclusive database
- Understanding of why direct cross-service table access is forbidden
- Awareness of the resulting need for API composition or sagas
- Ability to weigh the trade-off between autonomy and cross-service query complexity
Common Mistakes
- Suggesting services can share one database "for convenience"
- Forgetting that cross-service joins are no longer possible with plain SQL
- Not mentioning eventual consistency challenges introduced by this pattern
- Confusing database-per-service with simple database replication
Best Answer (HR Friendly)
“Database-per-service means every microservice has its own private database that nobody else is allowed to touch directly — if another service needs that data, it has to ask through an API. This keeps teams independent and lets each service pick its own database technology, but it means you can no longer just write one SQL join across services, so you need patterns like events or API composition to pull data together.”
Code Example
-- NOT allowed: Orders service directly querying Users service's database
SELECT u.email, o.total
FROM users_db.Users u
JOIN orders_db.Orders o ON o.user_id = u.id;
-- forbidden: reaches across a private service boundary
-- Allowed: each service queries only its own database
-- Orders service database:
SELECT user_id, total FROM Orders WHERE order_id = 501;
-- Users service database:
SELECT email FROM Users WHERE id = 42;
-- The Orders service then calls the Users service's API
-- (e.g. GET /users/42) instead of querying users_db directly.Follow-up Questions
- How do you run a query that needs data from two different services' databases?
- What is the saga pattern and how does it relate to this?
- How does database-per-service affect transactional consistency?
- What database technology choices might differ between services?
MCQ Practice
1. In the database-per-service pattern, how may one service access another service's data?
Each service's database is private; other services must go through its API or event stream, never direct table access.
2. What is a major trade-off of the database-per-service pattern?
Because each service's data is isolated, answering a query spanning services requires API composition, CQRS, or similar patterns instead of a join.
3. Which benefit does database-per-service provide?
Since no other service depends on a given service's internal schema, that service can change its tables freely without breaking others.
Flash Cards
What is database-per-service? — A pattern where each microservice owns a private database that no other service accesses directly.
How do services share data under this pattern? — Only through APIs or published events, never direct table access.
Main trade-off of database-per-service? — Cross-service queries and transactions become harder, requiring composition or saga patterns.
Benefit of database-per-service? — Each service can evolve its schema and pick its database technology independently.