Ce este principiul bazei de date per serviciu?

Question

Accepted Answer

**Baza de date per serviciu** înseamnă că fiecare microserviciu deține propria sa bază de date privată, și nicio altă serviciu nu poate să o citească sau să scrie în ea direct. Alte servicii trebuie să meargă prin API-ul serviciului proprietar.

## Cum funcționează

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

Dacă Orders are nevoie de date utilizator, apelează API-ul Users — **nu** interoghează `usersDB` direct.

## De ce să o impunem

- **Cuplaj slab** — un serviciu poate schimba liber schema sa.
- **Implementare independentă** — fără migrări de schema comună între echipe.
- **Alegerea tehnologiei** — un serviciu folosește Postgres, altul MongoDB.

## Costul

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

## Capcană

O **bază de date comună** este anti-patternul clasic — cuplează serviciile în tăcere, így nu mai pot fi implementate independent.

## De ce conteaza

Bazele de date private sunt ceea ce face ca serviciile să fie independent; împarte o bază de date și ai un monolitc distribuit.

Prețul este că joinurile și tranzacțiile acum se extinde pe servicii, ceea ce forțează modele cum ar fi sagas și eventual consistency — un compromis deliberat pentru autonomie.