Database per service: rule or guideline?
“Why do microservices insist on a database per service? What do you lose, and how do you answer a question that needs data from two services?”
What this tests
- Understanding that shared databases create schema coupling and coordinated deploys
- Honest accounting of what is lost: joins, transactions, a single reporting query
- Patterns for cross-service reads: API composition, replicated read models, events
- When a shared database is the pragmatic answer
Answers by level
Read the beginner answer first and notice what is missing.
The rule exists because a shared database is a shared schema, and a shared schema means every migration is a coordinated deploy across every service that touches the table. It also lets one service bypass another's business rules by writing to its tables directly. Private data plus a public API is what makes independent deployment real.
What you lose is significant: cross-service joins, cross-service Transactions and ACID, and the one SQL query that answered "revenue per region for orders placed by users who signed up this month". The replacements are API composition for small reads (call two services, join in memory — fine for one order, hopeless for a report), a replicated read model fed by events (the Analytics service consumes OrderPlaced and UserSignedUp and keeps its own denormalised table), and for reporting a warehouse fed by change data capture. Each replacement is eventually consistent.
So the rule is a strong default for ownership, not a law. Two services owned by one team with tightly coupled data are often better as one service.
Green flags · Red flags
- Explains the rule via schema coupling and coordinated deploys
- Lists what is lost: joins, transactions, ad hoc reporting
- Offers composition, event-fed read models and CDC with their consistency cost
- Mentions separate schemas in one cluster as a middle ground
- Willing to merge services rather than fake independence
- "Just let services read each other's tables for reporting; it is only reads."
- Proposes the gateway as the place to join data across services
- Does not mention eventual consistency of read models
- Believes the rule is about performance isolation rather than ownership