What is the database-per-service principle?

Question

Accepted Answer

**Database per service** means each microservice owns its own private database, and no other service may read or write it directly. Other services must go through the owning service's API.

## How it works

```text
┌──────────┐     ┌──────────┐     ┌──────────┐
│  Orders  │     │ Payments │     │  Users   │
│ service  │     │ service  │     │ service  │
└────┬─────┘     └────┬─────┘     └────┬─────┘
     ▼                ▼                ▼
  ordersDB        paymentsDB        usersDB   ← private, no cross-access
```

If Orders needs user data, it calls the Users API — it does **not** query `usersDB` directly.

## Why enforce it

- **Loose coupling** — a service can change its schema freely.
- **Independent deployment** — no shared-schema migrations across teams.
- **Technology choice** — one service uses Postgres, another uses MongoDB.

## The cost

```text
With no shared DB:
  ✗ no cross-service JOINs
  ✗ no single ACID transaction across services
  → need API composition, replication, or sagas instead
```

## Pitfall

A **shared database** is the classic anti-pattern — it silently couples services so they can no longer deploy independently.

## Why it matters

Private databases are what actually make services independent; share a database and you have a distributed monolith.

The price is that joins and transactions now span services, which forces patterns like sagas and eventual consistency — a deliberate trade for autonomy.