Quando a "Independência" vira um Pesadelo de Dados
Se você trabalha com microsserviços, já ouviu o mantra: "Microsserviços devem ser totalmente desacoplados. Share nothing (não compartilhe nada)."
A promessa é linda: serviços autônomos, times independentes, deploy a qualquer hora. Mas vamos ser honestos sobre o que acontece na prática quando levamos isso ao extremo. Na tentativa de eliminar qualquer dependência entre serviços, acabamos criando um monstro diferente: a Duplicação Massiva de Dados e a complexidade ingovernável da consistência.
Hoje, quero falar sobre por que buscar "Acoplamento Zero" é uma armadilha e como o Acoplamento Estratégico é a solução real.
A Armadilha do "Share Nothing"
Imagine que você tem um Serviço de Pedidos e um Serviço de Clientes. A regra do "acoplamento zero" diz que o Serviço de Pedidos não deve consultar o Serviço de Clientes para pegar o endereço de entrega, pois isso cria uma dependência em tempo de execução. A solução comum? Duplicar os dados. O Serviço de Pedidos mantém uma cópia local dos dados do cliente. Agora multiplique isso por 50 microsserviços. De repente, o endereço do cliente está replicado em 15 lugares diferentes. Se o cliente muda de endereço, você precisa disparar eventos para atualizar 15 bancos de dados. A consistência eventual vira uma dor de cabeça constante. Você trocou o acoplamento de serviço pelo acoplamento de dados, que é muito mais difícil de gerenciar.
A Solução: Acoplamento Estratégico (Bounded Contexts)
O segredo não é eliminar o acoplamento, mas escolher qual tipo de acoplamento você vai aceitar. Em vez de copiar tudo ou depender de tudo, usamos o conceito de Bounded Context (do DDD). O acoplamento é aceitável e necessário quando serve para manter a coerência de um processo de negócio, desde que seja fraco e assíncrono.
Exemplo Prático: O Carrinho de Compras
Vamos ver como isso funciona na prática para evitar a duplicação desnecessária.
Cenário: O Serviço de Checkout precisa saber o preço do produto que está no Serviço de Catálogo.
Abordagem Errada (Acoplamento Forte/Síncrono):
O Checkout faz um GET no Catálogo a cada requisição. Se o Catálogo cair, ninguém compra. O sistema é frágil.
Abordagem Errada (Acoplamento Zero/Duplicação Total):
O Checkout escuta eventos de ProdutoCriado e copia toda a tabela de produtos para seu próprio banco. Custo alto de armazenamento e complexidade de sincronização de preços.
Abordagem Correta (Acoplamento Estratégico):
O Checkout armazena apenas a Referência (ID) e o Snapshot Imutável no momento da transação. O Serviço de Checkout não precisa saber a descrição completa técnica do produto, nem suas fotos, nem seu fornecedor. Ele só precisa do ID e do Preço. Quando o usuário adiciona o item ao carrinho, o Checkout busca o preço uma vez (ou via cache distribuído) e grava um snapshot daquele item no pedido. Se o preço mudar no Catálogo 10 minutos depois, isso não deve afetar o pedido que já está em andamento. Aqui, aceitamos um acoplamento: o Checkout conhece o ID do produto (que pertence ao outro domínio). Mas é um acoplamento estratégico. Não duplicamos a lógica do produto, apenas referenciamos o que é necessário para fechar a venda.
Conclusão
Arquitetura é sobre trade-offs. Acoplamento Síncrono (RPC/HTTP): Mata a disponibilidade. Evite. Acoplamento de Dados (Replicação Total): Mata a consistência e a manutenção. Evite.
Acoplamento Estratégico (Referências e Eventos): Mantém a autonomia sem o caos dos dados. Pare de lutar contra o fato de que seus serviços precisam colaborar. Foque em definir fronteiras claras (Bounded Contexts) e use IDs e Eventos para transitar entre elas. É assim que sistemas distribuídos escalam de verdade.