Fără bază de date comună, nu puteți folosi JOINuri între servicii sau tranzacții ACID unice. Compuneți date și le mențineți consistente utilizând API composition, replication/CQRS read models și events.
— un coordonator apelează fiecare serviciu și unește rezultatul:
// 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
Pentru interogări grele, mențineți un read model (CQRS): un serviciu se abonează la evenimente și construiește o copie locală denormalizată pe care o poate interoga direct.
Orders ─event→ ┐
Users ─event→ ├─▶ [ Order-View service builds its own queryable table ]
Shipping ─event→ ┘
Utilizați modelul Saga — o secvență de tranzacții locale cu acțiuni compensatorii — în loc de o tranzacție distribuită.
| Abordare | Avantaj | Dezavantaj |
|---|---|---|
| API composition | Întotdeauna proaspăt | Latență, fan-out, fragil |
| Replicated read model | Citiri rapide | În final consistent |
| Saga | Fără 2PC necesar | Complex, necesită compensație |
Nu partajați pur și simplu un tabel pentru a ușura un join — asta re-cuplează serviciile. Acceptați consistență finală acolo unde afacerea o permite.
Gestiunea datelor este locul în care microserviciile devin cu adevărat dificile, deoarece instrumentele ușoare (joins, transactions) au dispărut prin design.
Înțelegerea composition, read models și sagas este ceea ce vă permite să mențineți serviciile independente fără a pierde corectitudine.