Database per Service

A Service Should Own Its Data

The Database per Service approach means that one service’s data is not a shared internal database for the others. Other components obtain required information through the owner’s contract instead of querying its tables directly.

Orders Service  -> Orders DB
Payments Service -> Payments DB

Payments Service -X-> Orders DB

Physically, this does not always require a separate database server. Logical ownership matters: only the owning service manages its data model and can safely change it without hidden consumers.

A Shared Database Creates Hidden Coupling

When several services read and modify the same tables, the schema becomes a shared API without explicit versioning. Renaming a column or changing the structure can no longer be done locally, and business rules are easily bypassed by direct writes from a neighboring service.

Owned storage forces communication through explicit contracts and better preserves the responsibility boundary. But data is now distributed, so a familiar JOIN across all entities and one shared transaction are no longer available as a universal solution.

Data Duplication Can Sometimes Be Acceptable

A service may keep a local representation of information received from another owner when this is needed for autonomous work or fast reads. Such a representation should have a clear source of truth and an update mechanism; otherwise copies will quietly diverge.