Database por serviço: quando a autonomia técnica tem preço alto
Dar a cada microsserviço seu próprio banco de dados resolve problemas de acoplamento — e cria problemas de consistência, custos operacionais e complexidade que precisam estar no plano.
O princípio correto e suas consequências
Database por serviço garante autonomia de deploy e desacoplamento real. O problema é que esse princípio tem consequências operacionais que raramente aparecem no diagrama de arquitetura.
Os trade-offs reais
- Consistência eventual — transações cross-serviços exigem patterns como Saga, com complexidade de compensação.
- Custo operacional multiplicado — cada banco adicional exige backup, monitoramento, patching e expertise operacional.
- Consultas cross-service — relatórios que cruzam domínios precisam de camada de dados dedicada (CQRS, data warehouse).
- Proliferação de tecnologias — liberdade sem governança vira zoo de bancos impossível de operar.
Quando faz sentido e quando não faz
Database por serviço faz sentido quando os domínios são realmente independentes e o time tem maturidade operacional para gerenciar múltiplos bancos. Para a maioria das empresas em crescimento, um banco compartilhado com schema bem estruturado é mais pragmático.
Próximo passo
Desenhando a arquitetura de dados do seu produto?
A rune.dev avalia trade-offs de arquitetura de dados com foco em operabilidade e custo de longo prazo.
Falar com um especialista →Precisa de apoio técnico no seu ambiente?
Diagnóstico sem compromisso. Retorno em até 48h úteis.