Se você presta atenção em conversas de tecnologia, “monolito” virou quase um xingamento. É a palavra que a gente usa para explicar por que o sistema antigo é difícil de mexer, por que o deploy demora, por que ninguém quer encostar naquele módulo. Como se o problema fosse a arquitetura em si.
Só que monolito não é sinônimo de bagunça. Bagunça é bagunça — e ela cabe muito bem dentro de microserviços também. Um monolito é só uma decisão de empacotamento: todo o código roda como uma unidade só. E, para a maioria dos projetos, essa continua sendo a escolha certa.
O que o monolito faz bem
Vale lembrar do que você ganha de graça quando tudo roda junto. Uma chamada entre partes do sistema é uma chamada de função: rápida, confiável, sem timeout. Uma operação que toca várias tabelas cabe numa transação de banco — ou tudo acontece, ou nada acontece. Depurar é abrir o código e seguir a linha de execução, não caçar uma requisição que se espalhou por seis serviços.
O deploy é um artefato só. O ambiente local é um comando só. E quando você precisa entender como uma feature funciona de ponta a ponta, está tudo ali, no mesmo repositório, sem precisar abrir cinco abas para reconstruir a história.
Isso não é preguiça. É velocidade. Nos primeiros anos de um produto, essa velocidade costuma valer mais do que qualquer diagrama bonito.
Onde o monolito começa a doer de verdade
Agora, ser justo com os dois lados: existe um ponto em que o monolito passa a atrapalhar. E o sinal quase nunca é técnico — é humano.
- Times pisando no pé um do outro. Quando cinco equipes disputam o mesmo código e todo deploy vira uma fila de espera, a unidade única começa a custar caro.
- Uma parte com necessidade radicalmente diferente. Um processamento de vídeo que precisa de máquinas gordas não deveria escalar junto com o seu CRUD de cadastro.
- Ritmos de mudança incompatíveis. Um núcleo estável que muda uma vez por trimestre preso ao mesmo ciclo de deploy de uma área que muda todo dia.
Repare que nenhum desses sinais é “o código está feio”. Código feio se resolve refatorando. O que justifica separar é quando a fronteira entre partes do sistema deixa de ser uma questão de organização e passa a ser uma questão de autonomia: times que precisam decidir, entregar e escalar sem depender uns dos outros.
Como resistir sem enfiar a cabeça na areia
Resistir à separação prematura não é fingir que o sistema nunca vai crescer. É preparar o terreno enquanto mantém a simplicidade. O truque é tratar o monolito como uma casa com cômodos bem definidos, e não como um galpão sem paredes.
Na prática, isso significa organizar o código por domínio, não por camada técnica. Em vez de uma pasta gigante de “controllers” e outra de “models”, você tem pedidos, pagamentos, estoque — cada um com suas regras dentro. E, principalmente, uma regra de ouro:
Um módulo não mexe direto no banco do outro. Ele pede, por uma interface. Se essa regra é respeitada, extrair um serviço depois é cirurgia. Se não é, vira demolição.
Quando os módulos só conversam por contratos explícitos, a linha pontilhada onde um dia você poderia cortar já está desenhada. O acoplamento fica visível, e o que estava implícito no meio do código vira uma fronteira que você controla.
A fronteira que importa é a dos dados
Se tem um critério que envelhece bem para decidir onde um sistema poderia se dividir, é o dado. Partes que compartilham as mesmas tabelas, que leem e escrevem no mesmo lugar o tempo todo, são fortes candidatas a continuarem juntas — separá-las só transforma um JOIN barato numa chamada de rede cara. Já partes que mal se tocam nos dados são fronteiras naturais.
Por isso, quando você organiza o monolito por domínio, o teste prático é olhar quem é dono de quais dados. Se dois módulos brigam o tempo todo pelas mesmas tabelas, eles provavelmente são um módulo só mal desenhado. Se cada um cuida do seu canto e conversa por interface, você já está com o mapa de uma futura separação na mão — mesmo que nunca precise usá-lo.
A decisão é reversível — até certo ponto
Um detalhe que muita gente ignora: sair de um monolito modular para serviços é relativamente tranquilo. O caminho inverso — juntar de volta microserviços que se provaram cedo demais — é doloroso e raramente acontece, porque ninguém tem coragem de assumir o retrabalho.
Por isso a assimetria importa. Começar simples e crescer é fácil. Começar complexo e simplificar é caro. Quando a decisão é reversível numa direção e travada na outra, a escolha prudente é começar pelo lado de onde dá para voltar.
O resumo honesto
Monolito não é dívida técnica. É uma escolha de empacotamento que, bem-feita, entrega mais valor por menos complexidade durante um bom tempo. Microserviços não são o próximo nível — são uma ferramenta específica para um problema específico de escala organizacional.
Se alguém no seu time fala em separar o sistema, a pergunta certa não é “para quantos serviços?”. É “que dor concreta a gente está sentindo hoje?”. Se a resposta vier fácil, com nome e sobrenome, talvez seja a hora. Se vier vaga, com “no futuro” e “para escalar”, o monolito ainda tem muita estrada pela frente.
