Med ingen delt database, kan du ikke bruke cross-service JOINs eller enkelte ACID-transaksjoner. Du komponerer data og holder den konsistent ved å bruke API composition, replication/CQRS read models og events.
— en koordinator kaller hver tjeneste og syr resultatet sammen:
// 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 tunge spørringer, vedlikeholder du en read model (CQRS): en tjeneste abonnerer på events og bygger en denormalisert lokal kopi den kan spørre direkte.
Orders ─event→ ┐
Users ─event→ ├─▶ [ Order-View service builds its own queryable table ]
Shipping ─event→ ┘
Bruk Saga-mønsteret — en sekvens av lokale transaksjoner med kompensasjonsaksjoner — i stedet for en distribuert transaksjon.
| Tilnærming | Fordel | Ulempe |
|---|---|---|
| API composition | Alltid frisk | Latency, fan-out, skjør |
| Replicated read model | Raske lesinger | Til slutt konsistent |
| Saga | Ingen 2PC nødvendig | Kompleks, krever kompensasjon |
Del ikke bare en tabell for å gjøre en join lett — det re-kobler tjenestene. Aksepter eventuell konsistens der virksomheten tillater det.
Datastyring er hvor microservices blir genuint vanskelig, fordi de enkle verktøyene (joins, transaksjoner) er borte ved design.
Å forstå composition, read models og sagas er det som gjør at du kan holde tjenestene uavhengige uten å miste korrekthet.