1. Introdução
Em busca de entregas rápidas, muitas equipes acabam recorrendo ao uso de um banco de dados compartilhado como meio de integração entre sistemas. Neste artigo, você vai entender por que essa “solução” pode se tornar um pesadelo de manutenção e governança, prejudicando escalabilidade e independência das equipes.
2. Definição do Anti-pattern
Banco Compartilhado (ou Integration Database) é o cenário em que múltiplos sistemas leem e escrevem diretamente nas mesmas tabelas e esquemas de um único banco de dados, sem camada de serviço intermediária.
“Multiple applications share one database schema, coupling their lifecycles and deployments too tightly.” — Martin Fowler, Bliki: Integration Database (25 May 2004)
Em contextos de microserviços, esse modelo é classificado como um anti-pattern, pois impede a autonomia de cada serviço e força coordenação constante entre equipes.
3. Principais Riscos e Impactos
- Acoplamento excessivo: mudanças de esquema exigem sincronização de deploys.
- Bloqueios e deadlocks: transações concorrentes entre serviços degradam performance.
- Governança frágil: falta de contrato de dados formal, sem versionamento claro.
- Perda de autonomia: serviços não podem escalar ou evoluir independentemente.
4. Sinais de Alerta
- Deploys bloqueados até que todas as equipes concordem com mudanças no banco.
- Consultas ad hoc de um serviço afetando latência de outro.
- Dificuldade de particionar dados ou migrar para novos storage engines.
5. Possíveis Alternativas / Boas Práticas
- Database per Service: cada serviço gerencia seu próprio armazenamento e expõe API REST/GRPC para acesso.
- Change Data Capture (CDC): propaga alterações por meio de eventos assíncronos.
- API Composition: combinar dados via chamadas de serviço em vez de SQL distribuído.
6. Lagrimas…
O Shared Database pode parecer uma solução rápida, mas traz consequências reais: retrabalho frequente, deploys sincronizados e riscos de bloqueios que afetam a produtividade. Cada alteração no esquema demanda coordenação entre equipes, atrasando ciclos de entrega e aumentando a complexidade operacional.
Reflita: a curto prazo pode até agilizar, mas a médio e longo prazo você estará refatorando consultas, ajustando deploys e resolvendo conflitos de dados. Prefira alternativas que garantam autonomia e flexibilidade desde a estruturação inicial dos seus sistemas.
Referências Teóricas
- Fowler, M. “Bliki: Integration Database”. 25 May 2004.
- Microservices.io. “Pattern: Shared database”. microservices.io
- Newman, S. Building Microservices. O’Reilly, 2015.
- Evans, E. Domain-Driven Design. Addison-Wesley, 2003.
