Database per service
Each service owns its data and no other service reads its tables directly; the others go through its API or its events.
A shared database couples services more tightly than any API: one schema change breaks three teams. With a database per service, each team can change its schema freely. The price is that joins across services are gone: a report needs a read model built from events (CQRS), and a change across services needs a saga.
Related terms
- Microservices: An architecture where a system is built from small, separately deployed services, each owning its data and talking to the others over the network.
- Saga pattern: A business process across several services run as a chain of local transactions, with a compensating action to undo each step if a later one fails.
- CQRS (Command Query Responsibility Segregation): Splitting a system into a write side that changes data and a separate read side shaped for queries, kept in sync by events.
