Kako upravljate podacima kada svaka usluga ima svoju bazu podataka?

Question

Accepted Answer

Bez **zajedničke baze podataka**, ne možete koristiti cross-service JOINove ili jedne ACID transakcije. Sastavljate podatke i održavate ih dosljedne koristeći **API sastav**, **replikaciju/CQRS modele čitanja** i **događaje**.

## Čitanje podataka između usluga

**API sastav** — koordinator poziva svaku uslugu i spaja rezultat:

```js
// build an order view from three services
const order    = await ordersApi.get(orderId);
const customer = await usersApi.get(order.customerId);   // separate service
const shipment = await shippingApi.get(orderId);
return { ...order, customer, shipment }; // composed in memory
```

Za teške upite, održavajte **model čitanja** (CQRS): usluga se pretplaćuje na događaje i gradi denormalizu lokalnu kopiju koju može izravno upitati.

```text
Orders ─event→ ┐
Users  ─event→ ├─▶ [ Order-View service builds its own queryable table ]
Shipping ─event→ ┘
```

## Pisanje između usluga

Koristite **Saga** uzorak — slijed lokalnih transakcija sa kompenzativnim akcijama — umjesto distribuirane transakcije.

## Kompromisi

| Pristup | Prednost | Nedostatak |
|---|---|---|
| API sastav | Uvijek svježe | Kašnjenje, fan-out, krhko |
| Replicirani model čitanja | Brzo čitanje | Na kraju dosljedna |
| Saga | Nema 2PC potrebe | Složeno, trebam nadoknadu |

## Zamka

Ne "dijelite" samo tablicu da olakšate spajanje — to ponovno povezuje usluge. Prihvatite eventualnu dosljednost gdje je dozvoljeno.

## Zašto je važno

Upravljanje podacima je mjesto gdje mikro-usluge postaju zaista teške, jer su jednostavni alati (spojevi, transakcije) otišli po dizajnu.

Razumijevanje sastava, modela čitanja i saga-a je ono što vam omogućava da službe ostanu neovisne bez gubitka ispravnosti.

Pristup	Prednost	Nedostatak
API sastav	Uvijek svježe	Kašnjenje, fan-out, krhko
Replicirani model čitanja	Brzo čitanje	Na kraju dosljedna
Saga	Nema 2PC potrebe	Složeno, trebam nadoknadu