Avec pas de base de données partagée, vous ne pouvez pas utiliser des JOINs cross-service ou des transactions ACID uniques. Vous composez les données et les gardez cohérentes en utilisant la composition d'API, la réplication/les modèles de lecture CQRS et les événements.
— un coordinateur appelle chaque service et assemble le résultat :
// 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
Pour les requêtes lourdes, maintenez un modèle de lecture (CQRS) : un service s'abonne aux événements et construit une copie locale dénormalisée qu'il peut interroger directement.
Orders ─event→ ┐
Users ─event→ ├─▶ [ Order-View service builds its own queryable table ]
Shipping ─event→ ┘
Utilisez le pattern Saga — une séquence de transactions locales avec des actions de compensation — au lieu d'une transaction distribuée.
| Approche | Avantage | Inconvénient |
|---|---|---|
| Composition d'API | Toujours frais | Latence, fan-out, fragile |
| Modèle de lecture répliqué | Lectures rapides | Finalement cohérent |
| Saga | Pas de 2PC nécessaire | Complexe, nécessite une compensation |
Ne "partagez" pas simplement une table pour faciliter une jointure — cela recouple les services. Acceptez la cohérence finalement lorsque le métier le permet.
La gestion des données est le point où les microservices deviennent réellement difficiles, car les outils faciles (jointures, transactions) ont disparu par conception.
Comprendre la composition, les modèles de lecture et les sagas vous permet de garder les services indépendants sans perdre la correction.