Sin una base de datos compartida, no puedes usar JOINs entre servicios ni transacciones ACID únicas. Compones datos y los mantienes consistentes usando composición de API, modelos de lectura replicados/CQRS y eventos.
— un coordinador llamada a cada servicio y une el resultado:
// 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
Para consultas pesadas, mantén un modelo de lectura (CQRS): un servicio se suscribe a eventos y construye una copia local desnormalizada que puede consultar directamente.
Orders ─event→ ┐
Users ─event→ ├─▶ [ Order-View service builds its own queryable table ]
Shipping ─event→ ┘
Usa el patrón Saga — una secuencia de transacciones locales con acciones compensatorias — en lugar de una transacción distribuida.
| Enfoque | Ventaja | Desventaja |
|---|---|---|
| Composición de API | Siempre fresco | Latencia, dispersión, frágil |
| Modelo de lectura replicado | Lecturas rápidas | Consistencia eventual |
| Saga | Sin 2PC necesario | Complejo, requiere compensación |
No "simplemente" compartas una tabla para hacer un join fácil — eso acoplará los servicios de nuevo. Acepta consistencia eventual donde el negocio lo permita.
La gestión de datos es donde los microservicios se vuelven genuinamente difíciles, porque las herramientas fáciles (joins, transacciones) se eliminan por diseño.
Entender composición, modelos de lectura y sagas es lo que te permite mantener servicios independientes sin perder corrección.