Czym jest zasada bazy danych na usługę?

Question

Accepted Answer

**Baza danych na usługę** oznacza, że każda mikrusługa posiada swoją prywatną bazę danych i żadna inna usługa nie może jej bezpośrednio czytać ani pisać. Inne usługi muszą komunikować się przez API usługi, która bazę posiada.

## Dlaczego to ważne

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

Jeśli Orders potrzebuje danych użytkownika, wywołuje Users API — **nie** wykonuje bezpośrednio zapytania do `usersDB`.

## Dlaczego to wymusić

- **Luźne sprzężenie** — usługa może swobodnie zmieniać swój schemat.
- **Niezależne wdrażanie** — bez migracji wspólnego schematu między zespołami.
- **Wybór technologii** — jedna usługa używa Postgres, inna MongoDB.

## Koszt

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

## Pułapka

**Wspólna baza danych** to klasyczny anti-pattern — cicho sprzęga usługi, tak że nie mogą być już niezależnie wdrażane.

## Dlaczego to ważne

Privatne bazy danych to to, co faktycznie czyni usługi niezależnymi; udostępnij bazę danych i masz rozproszony monolityk.

Ceną jest to, że joins i transakcje teraz obejmują wiele usług, co wymusza wzorce takie jak sagas i eventual consistency — świadomy kompromis dla autonomii.