Med ingen delt database kan du ikke bruge cross-service JOINs eller enkelt ACID-transaktioner. Du komponerer data og holder det konsistent ved hjælp af API-komposition, replikering/CQRS read models og events.
— en koordinator kalder hver service og kombinerer resultatet:
// 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
Til tunge forespørgsler skal du vedligeholde en read model (CQRS): en service abonnerer på events og bygger en denormaliseret lokal kopi, den kan forespørge direkte.
Orders ─event→ ┐
Users ─event→ ├─▶ [ Order-View service builds its own queryable table ]
Shipping ─event→ ┘
Brug Saga-mønsteret — en sekvens af lokale transaktioner med kompenserende handlinger — i stedet for en distribueret transaktion.
| Tilgang | Fordel | Ulempe |
|---|---|---|
| API-komposition | Altid frisk | Latens, fan-out, skrøbelig |
| Replikeret read model | Hurtige læsninger | Til sidst konsistent |
| Saga | Intet 2PC nødvendigt | Kompleks, kræver kompensation |
Del ikke "blot" en tabel for at gøre en join let — det re-koblet services. Accepter eventuel konsistens, hvor virksomheden tillader det.
Dataadministration er det sted, hvor microservices bliver virkelig hård, fordi de nemme værktøjer (joins, transaktioner) er væk ved design.
At forstå komposition, read models og sagas er det, der lader dig holde services uafhængige uden at miste korrekthed.