A Dor Real: O Microserviço que Virou Refém do Banco
O problema não começa no código, e sim na fronteira mal definida entre serviços. A maioria dos “microserviços” nasce com uma premissa falsa: cada um controla seu próprio banco. Só que no mundo real — com deadlines, sprint quebrado e pressão do negócio — serviços acabam disputando o mesmo schema, acessando dados que não deveriam e gerando relações cruzadas impossíveis de versionar.
Resultado? Você não tem microserviços. Você tem **um monólito distribuído**: lento, caro e difícil de manter.
O pior é que a galera percebe isso tarde demais, quando a query que deveria ser local vira uma fila de eventos que cai, perde mensagem e trava deploy.
A Solução Pragmática: Banco Como Fronteira, Não Como Dependência
Quer evitar esse colapso? Pare de quebrar o sistema baseado em tabelas, e comece a quebrar baseado em **contexto de negócio**. Só depois decida onde cada dado vive.
Alguns princípios que evitam a tragédia:
- Serviço sem autonomia de dados não é serviço — é API fina com dependência pesada.
- Eventos só funcionam se você controla cardinalidade e consistência.
- Se dois serviços precisam do mesmo banco todas as semanas, talvez não sejam dois serviços.
Microserviço é sobre independência. Se não dá independência ao banco, não há micro.
Implementação de Sênior: Exemplo Real com Schema por Bounded Context
Aqui vai um modelo de como separar o domínio de pagamentos e de pedidos, evitando o acoplamento tóxico que costuma nascer no banco:
-- Schema: orders (responsável pelo ciclo de vida de pedidos)CREATE TABLE orders.order ( id UUID PRIMARY KEY, customer_id UUID NOT NULL, total NUMERIC(10,2) NOT NULL, status VARCHAR(20) NOT NULL, created_at TIMESTAMP NOT NULL);-- Schema: payments (responsável pela liquidação financeira)CREATE TABLE payments.transaction ( id UUID PRIMARY KEY, order_id UUID NOT NULL, amount NUMERIC(10,2) NOT NULL, status VARCHAR(20) NOT NULL, paid_at TIMESTAMP, CONSTRAINT fk_order_ref FOREIGN KEY (order_id) REFERENCES orders.order (id));Repare no detalhe crítico: o serviço de pagamentos usa o order_id como referência, mas não precisa acessar o domínio inteiro de pedidos. O contrato é o ID, ponto.
Se amanhã o serviço de pedidos mudar o fluxo interno, o banco de pagamentos continua íntegro.
Direto das Trincheiras
- Se um microserviço só existe porque sua empresa quer parecer cool na arquitetura, corte-o pela raiz.
- Não coloque em eventos aquilo que deveria ser uma simples transação ACID.
- Monitoramento de banco separado por domínio vale mais que qualquer dashboard de tracing.
O Custo da Escolha: Escalar com Micro ou com Monólito?
Fragmentar cedo demais cria **over-engineering**. Fragmentar tarde demais cria **dívida técnica**. Decidir pelo microserviço significa assumir custos reais: duplicação de dados, complexidade operacional e perda de visibilidade global.
Mas manter tudo num monólito também cobra seu preço: deploy lento, modelo de dados inchado e gargalos de performance.
O segredo é simples (mas não fácil): **faça a divisão quando o negócio pede, não quando o hype empurra**.
Fontes
Quando Microserviços Se Revelam Monólitos Distribuídos
O Dilema de Adotar Novas Tecnologias em Engenharia de Software
Fechando
Obrigado por acompanhar essa reflexão até o fim!
Espero que isso ajude você a evitar armadilhas arquiteturais no próximo projeto — especialmente quando o banco de dados vira palco da guerra. Não deixe de conferir outros artigos no blog reymaster.dev.br.
Valeu e até a próxima! 😉
