Como quebrar monolito ou sistema acoplado

O problema

Tem time que olha para um sistema grande e conclui:

“O problema e que isso ainda e um monolito.”

As vezes e.

Mas muitas vezes o problema real e outro:

• módulo sem fronteira
• regra espalhada
• ownership confuso
• deploy arriscado
• dependência circular

Se você chama tudo isso de “monolito” e sai quebrando o sistema em pedacos, pode trocar uma bagunca conhecida por uma bagunca distribuida.

Modelo mental

Pense assim:

quebrar monolito e separar responsabilidade sem perder controle operacional

O ponto não e o número de repositorios ou de serviços.

E responder:

• o que realmente precisa evoluir separado
• onde existe uma fronteira real
• que dependências precisam continuar estaveis durante a transição
• qual custo operacional aparece depois da extração

Quando a resposta para isso não existe, a quebra ainda esta imatura.

Quebrando o problema

Descubra se o problema e topologia ou falta de fronteira

Monolito ruim existe.

Também existe monolito que só esta mal organizado.

Antes de extrair, vale perguntar:

• esse fluxo precisa de escala, deploy ou ownership separados?
• ou ele só precisa de melhor modularizacao interna?

Se a segunda pergunta resolver, talvez ainda não seja hora de distribuir nada.

Escolha a fronteira pelo comportamento, não pelo nome bonito

Fronteira ruim costuma nascer assim:

• “vamos extrair pagamentos porque parece importante”
• “vamos criar serviço de usuário porque toda empresa tem”

Fronteira melhor nasce de algo mais concreto:

• caso de uso que muda em ritmo diferente
• dependência externa isolavel
• fluxo que precisa de resiliencia própria
• parte do sistema que já se comporta como unidade

Extrair porque o discurso de arquitetura mandou quase sempre sai pior do que extrair pelo comportamento real.

Compare o custo novo que você vai comprar

Quando algo sai do mesmo processo e vira dependência remota, você compra:

• rede
• timeout
• retry
• observabilidade
• versionamento de contrato
• risco operacional novo

Se a extração não compensa esse pacote, talvez você esteja celebrando problema novo como se fosse maturidade.

Separe acesso antes de separar deploy

Muita quebra de monolito funciona melhor quando você primeiro cria uma fronteira de acesso:

• facade
• módulo claro
• camada de aplicação
• contrato explícito

Isso deixa a separação técnica menos arriscada depois.

Sem esse passo, a extração costuma arrastar dependência escondida junto.

Mova um fluxo e meca de verdade

Não tente provar a estratégia extraindo metade do sistema.

Escolha um fluxo.

Veja se você consegue:

• rotear com clareza
• observar erro e latência
• manter compatibilidade
• desligar o caminho antigo depois

Se não consegue com uma parte pequena, dificilmente vai conseguir com o resto.

Exemplo simples

Imagine um monolito de e-commerce com catalogo, checkout, frete e notificação.

O time quer quebrar tudo em serviços.

Plano fraco:

• criar quatro serviços de uma vez
• mover tabelas
• reescrever integração interna

Plano melhor:

1. isolar um fluxo que já conversa com terceiro, como cotacao de frete
2. criar uma fronteira clara de acesso para esse fluxo
3. mover só essa parte primeiro
4. medir impacto operacional real
5. decidir a proxima extração com base no que foi aprendido

Isso ensina mais do que vinte diagramas.

Erros comuns

• Tratar microsservico como premio de maturidade.
• Escolher fronteira com base em moda, não em comportamento real.
• Extrair sem considerar custo de rede, contrato e operação.
• Tentar mover muitos fluxos ao mesmo tempo.
• Ignorar que modularizacao interna pode resolver parte grande do problema.

Como um senior pensa

Quem tem mais experiência não pergunta primeiro:

“Quantos serviços isso vai virar?”

Pergunta mais isto:

“Qual dependência eu preciso afrouxar, e qual e o menor movimento que prova isso sem piorar o sistema?”

Essa pergunta costuma produzir uma arquitetura menos performatica e mais útil.

O que o entrevistador quer ver

Em entrevista, o avaliador quer ver critério, não entusiasmo por distribuição.

Você sobe de nivel quando:

• separa problema de acoplamento e problema de topologia
• fala de fronteira real e custo operacional
• reconhece que monolito nem sempre e o inimigo
• propoe extração incremental em vez de revolucao abstrata

Uma resposta forte costuma soar assim:

“Eu não quebraria um monolito por principio. Primeiro verificaria se o problema pede deploy, escala ou ownership separados. Se pedisse, escolheria uma fronteira pequena e real, criaria contrato claro e só entao extrairia com observabilidade e rollback.”

Distribuir sistema sem necessidade não e evolução. E multiplicacao de problema.

O monolito só deixou de ser aceitavel quando a fronteira interna deixou de ser suficiente.