The shared database trap
If many services share one database, they couple through its schema. One service changing a table can break others, and the database becomes a single bottleneck.
The pattern
With database per service, each service owns its own private store. Other services may only reach that data through the service API, never by direct database access.
- Each service can pick the store that fits, relational or document.
- Schema changes stay local and safe.
- The service deploys and scales independently.
The hard part
You lose easy cross-service joins and ACID transactions across services. To keep consistency you use:
- API composition for reads.
- Sagas for multi-service writes.
This is the trade: independence in exchange for handling consistency yourself.
Key idea
Database per service gives each service a private store for independence, but you must replace cross-service joins and transactions with composition and sagas.