Utan en delad databas kan du inte använda JOINs mellan tjänster eller enskilda ACID-transaktioner. Du komponerar data och håller det konsistent med hjälp av API-komposition, replikerade/CQRS read models och events.
— en koordinator anropar varje tjänst och syr ihop 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
För tunga frågor, underhåll en read model (CQRS): en tjänst prenumererar på events och bygger en denormaliserad lokal kopia som du kan fråga direkt.
Orders ─event→ ┐
Users ─event→ ├─▶ [ Order-View service builds its own queryable table ]
Shipping ─event→ ┘
Använd Saga-mönstret — en sekvens av lokala transaktioner med kompenserande åtgärder — istället för en distribuerad transaktion.
| Tillvägagångssätt | Pro | Con |
|---|---|---|
| API-komposition | Alltid aktuell | Latens, fan-out, skör |
| Replikerad read model | Snabba läsningar | Slutligen konsistent |
| Saga | Ingen 2PC behövs | Komplex, behöver kompensation |
Dela inte "bara" en tabell för att göra en JOIN enkel — det omkopplar tjänsterna igen. Acceptera slutlig konsistens där verksamheten tillåter.
Datahantering är där microservices blir genuint svårt, eftersom de enkla verktygen (joins, transactions) är borta enligt design.
Att förstå komposition, read models och sagas är vad som låter dig hålla tjänsterna oberoende utan att förlora riktighet.