đ Monolith to Microservices
Database per Service Pattern
Why microservices must own their data â and what happens when they don't
Database per Service is the most violated microservices principle. Teams often start with separate services but a shared database â this is called a Distributed Monolith, and it's worse than a regular monolith because you pay the network overhead without getting any isolation benefits.
Key Concepts
Data Ownership
A service's database is an implementation detail. Just like private class fields, other services must not access it directly â only through the service's public API.
No Cross-Service Joins
When services share a database, a DBA can add a JOIN that couples two 'independent' services forever. Schema changes in Service A break Service B silently.
Data Duplication is OK
Denormalizing and duplicating data across services is acceptable and often required. The Order service stores productName at purchase time so it doesn't depend on Catalog service being alive.
Anti-Pattern vs Best Practice
Patterns for Cross-Service Data Access
| Pattern | How It Works | When to Use |
|---|---|---|
| API Composition | Service A calls Service B's REST/gRPC API to get needed data | Real-time reads, small data volumes, simple aggregation |
| Event-Driven Sync | Service B publishes events when data changes; Service A maintains its own read copy | High-read scenarios, tolerance for eventual consistency |
| CQRS Read Model | Dedicated read-optimized DB fed by events (e.g., Elasticsearch) | Complex queries across domains, reporting, search |
| Saga Pattern | Chain of local transactions with compensating rollbacks for write coordination | Cross-service write operations that must be atomic |
đĄ
Senior Architect Insight: The acid test: can you change a service's database schema (rename a column, switch databases) without touching any other service's code? If the answer is no, you have a shared-database problem.