Article 11: Database per Microservice

1. Objective

Understand why each microservice must own its own database and how this enables loose coupling and scalability.

2. Key Concepts

• Database-per-service pattern
• Data ownership
• Loose coupling
• Schema isolation

3. Why Shared Database Is a Bad Idea

Shared databases lead to:

• Tight coupling between services
• Deployment dependencies
• Risk of accidental data corruption
• Inability to scale independently

4. Recommended Architecture

[User Service]    ---> User DB
[Order Service]   ---> Order DB
[Payment Service] ---> Payment DB

5. Hands-On: Separate Databases

Example configuration:

User Service:

spring:
  datasource:
    url: jdbc:h2:mem:userdb

Order Service:

spring:
  datasource:
    url: jdbc:h2:mem:orderdb

6. Handling Cross-Service Data

Recommended approaches:

• REST API calls
• Event-driven updates
• Read-only data duplication

7. What NOT To Do

• Foreign keys across services
• Cross-database joins
• Shared schemas

8. Interview Notes

• Database-per-service ensures autonomy
• Enables independent scaling and deployment

9. Summary

Each microservice must fully own its data. This is non-negotiable in real microservice systems.

10. What’s Next

Learn how to handle transactions that span multiple services.