Con nessun database condiviso, non puoi usare JOIN tra servizi o transazioni ACID singole. Componi i dati e mantienili consistenti usando composizione API, modelli di lettura replicati/CQRS e eventi.
— un coordinatore chiama ogni servizio e assembla il risultato:
// 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
Per query pesanti, mantieni un modello di lettura (CQRS): un servizio si sottoscrive agli eventi e costruisce una copia locale denormalizzata che può interrogare direttamente.
Orders ─event→ ┐
Users ─event→ ├─▶ [ Order-View service builds its own queryable table ]
Shipping ─event→ ┘
Usa il pattern Saga — una sequenza di transazioni locali con azioni di compensazione — invece di una transazione distribuita.
| Approccio | Pro | Contro |
|---|---|---|
| Composizione API | Sempre fresco | Latenza, fan-out, fragile |
| Modello di lettura replicato | Letture veloci | Eventualmente consistente |
| Saga | Nessun 2PC necessario | Complesso, richiede compensazione |
Non "semplicemente" condividere una tabella per fare un join facile — questo ricollega i servizi. Accetta la consistenza eventuale dove il business lo consente.
La gestione dei dati è dove i microservizi diventano davvero difficili, perché gli strumenti facili (join, transazioni) sono eliminati per design.
Capire la composizione, i modelli di lettura e le saga è quello che ti permette di mantenere i servizi indipendenti senza perdere la correttezza.