DatabasePerService [pattern] v1.0.0

Each microservice has a private database. No other service reads or writes that database directly — they go through the owning service's API. The schema is an internal implementation detail, free to evolve. The price is that joins across services are no longer SQL joins; they become API calls or async data flows.

Label

Database per Service — each service owns its data exclusively

Problem

A shared database is a point of coupling that defeats microservices. Schema changes block every team that touches a column. Two services accessing the same table with different assumptions corrupt each other's invariants. Scaling the DB scales for the union of all services' needs.

Solution

    Each service owns its tables / its database / its database server.

      Order Service     → orders_db   (schema: orders, order_items)
      Inventory Service → inventory_db (schema: items, reservations)
      User Service      → users_db    (schema: users, sessions)

    Cross-service queries:
      - Synchronous: API call to the owning service.
      - Asynchronous: subscribe to events; maintain a local read model
        (see CQRS).

    Cross-service transactions: use Saga.
  

DatabasePerService [pattern] v1.0.0

Each microservice has a private database. No other service reads or writes that database directly — they go through the owning service's API. The schema is an internal implementation detail, free to evolve. The price is that joins across services are no longer SQL joins; they become API calls or async data flows.

Label

Database per Service — each service owns its data exclusively

Problem

A shared database is a point of coupling that defeats microservices. Schema changes block every team that touches a column. Two services accessing the same table with different assumptions corrupt each other's invariants. Scaling the DB scales for the union of all services' needs.

Solution

    Each service owns its tables / its database / its database server.

      Order Service     → orders_db   (schema: orders, order_items)
      Inventory Service → inventory_db (schema: items, reservations)
      User Service      → users_db    (schema: users, sessions)

    Cross-service queries:
      - Synchronous: API call to the owning service.
      - Asynchronous: subscribe to events; maintain a local read model
        (see CQRS).

    Cross-service transactions: use Saga.
  

Relations

enhances: [@backend-architecture/principle-backing-services-attached]

Label

Database per Service — each service owns its data exclusively

Problem

A shared database is a point of coupling that defeats microservices. Schema changes block every team that touches a column. Two services accessing the same table with different assumptions corrupt each other's invariants. Scaling the DB scales for the union of all services' needs.

Solution

    Each service owns its tables / its database / its database server.

      Order Service     → orders_db   (schema: orders, order_items)
      Inventory Service → inventory_db (schema: items, reservations)
      User Service      → users_db    (schema: users, sessions)

    Cross-service queries:
      - Synchronous: API call to the owning service.
      - Asynchronous: subscribe to events; maintain a local read model
        (see CQRS).

    Cross-service transactions: use Saga.
  

Enhances

• @backend-architecture/principle-backing-services-attached