Database-per-service and a shared database are the two main data-ownership strategies in microservices, and database-per-service is generally the preferred default because it preserves service independence.
Key Points: • Each service owns its schema and data, so no other service can bypass its API and read or write its tables directly. • Services can pick the database technology that fits their access pattern, for example a relational store for orders and a document store for a catalog. • Schema changes in one service cannot break another service, which lets teams deploy independently. • The trade-off is added complexity around cross-service queries and consistency, which typically requires patterns like the Saga pattern or event-driven synchronization instead of joins or shared transactions. • A shared database can still make sense for a small, tightly coupled system in its early stages, but it quickly becomes a coupling bottleneck as the number of services grows.
Example: In an order-management system, the Order service might use PostgreSQL for transactional order data while the Search service maintains its own Elasticsearch index, kept in sync through domain events rather than a shared table.
Interview Tip: A concise interview answer is:
"I'd default to database-per-service because it keeps services independently deployable and lets each pick the right storage technology, even though it means handling cross-service consistency with patterns like Saga or events instead of joins or shared transactions. A shared database only makes sense for a very small, early-stage system."