Understanding Database per Service in Microservices Architecture

Introduction

In microservices architecture, the Database per Service pattern is crucial for maintaining autonomy and reducing coupling between services. This concept ensures that each microservice owns its data, which is essential for independent development and deployment.

The Shared Database Problem

• When multiple services (like Order, Payment, and Inventory) share the same database schema, changes in one service can impact others.
• This leads to schema-level coupling, making it difficult to evolve services independently.

What Is Database per Service?

• Each microservice should own its domain data, controlling access to its own persistence layer.
• Examples:
  • Order Service → Owns Order Data
  • Payment Service → Owns Payment Data
  • Inventory Service → Owns Inventory Data
• Note: Owning data does not necessarily mean a separate physical database server is required. Logical separation (schemas) can also be effective.

How Do Services Share Data?

• Services should not directly access each other's databases. Instead, they can communicate through:
  • APIs: Requesting data or invoking actions.
  • Events: Publishing events like OrderCreated or PaymentCompleted.
  • Read Models: Creating query-friendly views for data needed from multiple services.

Benefits of Database per Service

• Clearer Data Ownership: Each service knows its data.
• Reduced Schema-Level Coupling: Changes in one service do not affect others.
• Greater Service Autonomy: Services can evolve independently.
• Independent Evolution of Persistence: Each service can choose its database technology if needed.

Trade-Offs

• Cross-service queries become complex. Instead of a simple SQL JOIN, you might need API composition or dedicated read models.
• Business operations that span multiple services may require distributed workflows, leading to complexities in consistency. Patterns like Saga or Transactional Outbox can help manage these complexities.

Conclusion

In system design interviews, it’s important to explain not just the concept of Database per Service, but also the data ownership, access, and inter-service communication strategies. This demonstrates a deeper understanding of microservices architecture.