Zonder gedeelde database, kunt u geen cross-service JOINs of enkele ACID-transacties gebruiken. U stelt gegevens samen en houdt deze consistent met API composition, replication/CQRS read models en events.
— een coördinator roept elke service aan en stelt het resultaat samen:
// 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
Voor zware query's onderhoudt u een read model (CQRS): een service abonneert zich op events en bouwt een gedenormaliseerde lokale kopie die het rechtstreeks kan opvragen.
Orders ─event→ ┐
Users ─event→ ├─▶ [ Order-View service builds its own queryable table ]
Shipping ─event→ ┘
Gebruik het Saga-patroon — een reeks lokale transacties met compenserende acties — in plaats van een gedistribueerde transactie.
| Aanpak | Voordeel | Nadeel |
|---|---|---|
| API composition | Altijd vers | Latency, fan-out, fragiel |
| Replicated read model | Snelle lezingen | Uiteindelijk consistent |
| Saga | Geen 2PC nodig | Complex, vereist compensatie |
Deel niet zomaar een tabel om een join eenvoudig te maken — dat koppelt services opnieuw. Accepteer uiteindelijke consistentie waar het bedrijf dit toestaat.
Gegevensbeheer is waar microservices echt moeilijk worden, omdat de eenvoudige tools (joins, transacties) opzettelijk verdwenen zijn.
Het begrijpen van composition, read models en sagas is wat u in staat stelt services onafhankelijk te houden zonder correctheid te verliezen.