How do you manage data when each service has its own database?

Question

Accepted Answer

With **no shared database**, you can't use cross-service JOINs or single ACID transactions. You compose data and keep it consistent using **API composition**, **replication/CQRS read models**, and **events**.

## Reading data across services

**API composition** — a coordinator calls each service and stitches the result:

```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
```

For heavy queries, maintain a **read model** (CQRS): a service subscribes to events and builds a denormalized local copy it can query directly.

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

## Writing across services

Use the **Saga** pattern — a sequence of local transactions with compensating actions — instead of a distributed transaction.

## Trade-offs

| Approach | Pro | Con |
|---|---|---|
| API composition | Always fresh | Latency, fan-out, fragile |
| Replicated read model | Fast reads | Eventually consistent |
| Saga | No 2PC needed | Complex, needs compensation |

## Pitfall

Don't "just" share a table to make a join easy — that re-couples services. Accept eventual consistency where the business allows.

## Why it matters

Data management is where microservices get genuinely hard, because the easy tools (joins, transactions) are gone by design.

Understanding composition, read models, and sagas is what lets you keep services independent without losing correctness.

Approach	Pro	Con
API composition	Always fresh	Latency, fan-out, fragile
Replicated read model	Fast reads	Eventually consistent
Saga	No 2PC needed	Complex, needs compensation