Quando boas práticas viram dogmas: o problema das verdades absolutas em arquitetura

Arquitetura de software sofre de um problema recorrente: recomendações que nasceram como alertas técnicos acabam sendo repetidas como leis universais. Com o tempo, o contexto se perde e sobra apenas a regra, aplicada de forma automática, mesmo quando o cenário não justifica.

Microsserviços e bancos de dados são um dos exemplos mais claros disso: A afirmação “cada microserviço deve ter seu próprio banco” é amplamente difundida, muitas vezes sem qualquer qualificação. Em certos contextos, ela é correta. Em outros, é apenas uma simplificação perigosa.

O problema não está na recomendação original, mas na forma como ela é tratada como verdade absoluta.

Por que essas regras surgem

Essas orientações não surgiram do nada. Elas nasceram como resposta a problemas reais observados em sistemas distribuídos ao longo dos anos. Compartilhar banco de dados entre serviços frequentemente gera contenção de recursos, acoplamento de schema e evolução coordenada entre times. Em muitos casos, isso de fato destrói a autonomia prometida pelos microsserviços.

O erro começa quando essa observação vira uma regra genérica, aplicada sem análise do caminho crítico do sistema, do tipo de carga envolvida ou do estágio de maturidade do produto.

Arquitetura não é uma coleção de slogans. É uma disciplina de tomada de decisão sob restrições.

O que realmente torna o banco compartilhado um problema

O banco de dados não é um problema por existir. Ele se torna um problema quando entra no caminho crítico do sistema de forma errada.

Na maioria dos casos em que o padrão “banco compartilhado” causa falhas, dois fatores estão presentes. O primeiro é a contenção de recursos. Serviços diferentes passam a disputar CPU, I/O e locks no banco, fazendo com que cargas analíticas ou processamentos pesados degradem operações transacionais simples.

O segundo fator é o acoplamento evolutivo. Mudanças de schema precisam ser coordenadas, deploys passam a acontecer juntos e times começam a evitar evoluções por medo de quebrar outros consumidores. O sistema não cai, mas para de evoluir com velocidade.

Esses são problemas reais. Mas eles não existem em todos os cenários.

Quando o gargalo não é o banco

Considere um microsserviço criado especificamente para lidar com processamento intensivo de CPU. Ele consome dados de forma simples, com consultas previsíveis, bem indexadas e sem agregações pesadas. O processamento ocorre majoritariamente fora do banco, na memória e no processador da própria aplicação.

Nesse cenário, o banco não está no caminho crítico. O gargalo não é I/O, não são locks e não é concorrência no banco. O gargalo é computacional.

Separar esse processamento em um serviço dedicado faz sentido técnico claro, pois permite escalar CPU e memória de forma independente. Conectar esse serviço ao mesmo banco não cria automaticamente um problema sistêmico. O risco deixa de ser imediato e passa a ser potencial.

Tratar esse cenário como erro arquitetural é dogmatismo, não engenharia.

O verdadeiro risco é evolutivo, não técnico imediato

Mesmo quando o banco não é o gargalo hoje, ainda existe um risco real, mas ele é de longo prazo. Com o tempo, demandas mudam. O processamento simples pode virar analítico. Consultas começam a cruzar histórico. O volume cresce e o que era CPU-bound passa a ser data-bound.

Quando isso acontece, a arquitetura que era aceitável deixa de ser. O erro não está em ter tomado a decisão inicial, mas em não ter deixado uma rota clara de saída.

Arquitetura madura não tenta prever o futuro com precisão impossível. Ela cria espaço para mudança sem trauma.

Aceitar trade-offs conscientemente é parte do trabalho

Usar o mesmo banco em determinados cenários não é negligência, desde que seja uma decisão consciente. Isso significa entender exatamente quais riscos estão sendo aceitos e quais não estão presentes naquele momento.

Se o serviço não escreve dados compartilhados, se as queries são simples, se o banco não está sob pressão e se o time consegue coordenar mudanças de schema quando necessário, o acoplamento existe, mas é controlável.

Isso não é arquitetura errada. É arquitetura pragmática.

O perigo real das verdades absolutas

O maior problema de tratar recomendações como leis é que isso empurra equipes para arquiteturas complexas cedo demais. Sistemas passam a adotar replicação de dados, pipelines de eventos e mecanismos sofisticados para resolver problemas que ainda não existem.

O custo dessas decisões é imediato. Infraestrutura mais cara, observabilidade mais complexa, debug mais difícil e times mais lentos. Em troca, ganha-se uma proteção teórica contra riscos que talvez nunca se materializem.

Arquitetura não é sobre estar certo no futuro. É sobre não pagar caro demais no presente.

Quando a resposta correta é “ainda não sei”

Um ponto raramente discutido é que “não sei” também é uma resposta válida em arquitetura. Quando não é possível afirmar se um banco vai virar gargalo, se o workload vai mudar ou se o domínio vai crescer, a decisão correta não é maximizar robustez, mas minimizar custo e maximizar observabilidade.

Escolher a solução mais simples que permita medir, aprender e corrigir depois é muitas vezes a decisão mais madura possível.

Dogmas não lidam bem com incerteza. Engenharia lida.

Conclusão

Microsserviços não falham por compartilharem banco de dados. Eles falham quando o banco entra no caminho crítico errado ou quando o acoplamento deixa de ser consciente.

Boas práticas existem para evitar problemas recorrentes, não para eliminar o pensamento crítico. Toda recomendação arquitetural só faz sentido quando aplicada dentro de um contexto específico, com riscos conhecidos e limites claros.

Arquitetura boa não elimina incerteza. Ela convive com ela sem transformar cada decisão em um compromisso irreversível.