Why does each microservice need its own database?
Assesses fundamental understanding of Microservices conventions, runtime behavior, and memory/performance considerations.
Hiring managers look for precision, avoidance of ambiguous jargon, and ability to explain trade-offs under real production conditions.
Owning its data is what makes a service independently deployable. With a shared database, a schema change in one service can break another, teams coordinate releases, and the database becomes a hidden coupling point. Database-per-service enforces encapsulation: other services can only reach the data through a published API or events.
Benefits: independent schema evolution, freedom to choose the right store (relational, document, search, time-series), and failure isolation. Costs: no cross-service joins or foreign keys, so you compose data in the application or maintain read models, and consistency becomes eventual.
order-service -> orders_db
user-service -> users_db
To keep read models fresh, services publish domain events and consumers project the data they need, using the outbox pattern for reliability. Avoid the trap of one database server with logical separation but shared credentials and direct cross-schema queries: that is still a distributed monolith.
Candidate Response Strategy & Interview Tips
- Start with a concise one-sentence summary: Deliver a direct, confident answer first before expanding into nuances.
- Demonstrate real-world trade-offs: Discuss where this approach excels and when you would avoid it in production systems.
- Discuss complexity & edge cases: Proactively explain time/space complexity or boundary conditions (null values, scale limits).
- Prepare for interviewer follow-ups: Technical hiring panels frequently probe deeper into concurrency, backward compatibility, or alternative libraries.