The database-per-service pattern means each microservice owns and exclusively accesses its own database, rather than sharing a single database across services.
Key Points: • It enforces true independence — a service can change its schema or even switch database technology without coordinating with other teams. • It prevents services from silently coupling through shared tables, which is one of the most common ways microservices architectures accidentally become distributed monoliths. • Isolating databases improves security, since a breach or bug in one service can't directly expose or corrupt another service's data. • Each service can scale its database independently based on its own load characteristics rather than being constrained by a shared instance. • The trade-off is that cross-service queries and transactions become harder, requiring patterns like the Saga pattern or API composition instead of a simple SQL join.
Example: An Order Service using PostgreSQL and a Product Catalog Service using MongoDB can each pick the database best suited to their access patterns, and a schema change in the Order Service's tables never risks breaking the Catalog Service.
Interview Tip: A concise interview answer is:
"Separate databases per service keep services truly independent — no shared schema means one team can change or scale their database without coordinating with others, and it limits the blast radius of a security or data issue to a single service. The cost is that queries spanning multiple services need patterns like sagas or API composition instead of a simple join."