Sem banco de dados compartilhado, você não pode usar JOINs entre serviços ou transações ACID únicas. Você compõe dados e mantém consistência usando API composition, replication/CQRS read models e events.
— um coordenador chama cada serviço e une o 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, mantenha um read model (CQRS): um serviço se inscreve em eventos e constrói uma cópia local desnormalizada que pode consultar diretamente.
Orders ─event→ ┐
Users ─event→ ├─▶ [ Order-View service builds its own queryable table ]
Shipping ─event→ ┘
Use o padrão Saga — uma sequência de transações locais com ações compensatórias — em vez de uma transação distribuída.
| Abordagem | Vantagem | Desvantagem |
|---|---|---|
| API composition | Sempre atualizado | Latência, fan-out, frágil |
| Replicated read model | Leituras rápidas | Eventualmente consistente |
| Saga | Sem 2PC necessário | Complexo, requer compensação |
Não simplesmente compartilhe uma tabela para facilitar um join — isso re-acopla os serviços. Aceite consistência eventual onde o negócio permite.
Gerenciamento de dados é onde microservices ficam genuinamente difíceis, porque as ferramentas fáceis (joins, transactions) desapareceram por design.
Compreender composition, read models e sagas é o que permite manter serviços independentes sem perder correção.