Reescrever ou estrangular o monolito? O guia decisório para escalar sem parar o negócio

O primeiro critério é o grau de acoplamento entre negócio e código. Se uma mudança simples em uma área do produto quebra fluxos de cobrança, autenticação ou relatórios, a arquitetura já está cobrando juros compostos. Se o time demora semanas para entender o impacto de uma alteração, o problema deixou de ser elegância técnica e passou a ser previsibilidade operacional. A pergunta não é se o monolito é “feio”, mas se ele ainda permite mudança segura. O segundo critério é o custo de oportunidade da dívida técnica. Quando o time passa mais tempo corrigindo efeitos colaterais do que entregando valor, a empresa está financiando atraso. Em produtos B2B, isso costuma aparecer como queda de velocidade de resposta ao cliente enterprise, piora de performance em picos de uso e atraso em features que sustentam expansão comercial. Em empresas em rodada, esse atraso também pesa na due diligence técnica, porque investidor e comprador procuram sinais de sustentação, não apenas promessas. O terceiro critério é o nível de incerteza sobre o futuro do produto. Se a empresa ainda está testando proposta de valor, reescrever tudo cedo demais costuma ser um erro clássico. Já se o produto validou demanda, mas a base técnica impede escala, o estrangulamento progressivo costuma ser mais racional. Essa lógica conversa bem com o blueprint de produto digital com IA, AR/VR e software sob medida, porque o desenho de arquitetura precisa acompanhar estágio, mercado e ambição comercial. O quarto critério é a capacidade interna de execução. Reescrever exige mais concentração, mais senioridade e mais disciplina para não cair no “novo monolito”. Estrangular exige coordenação entre módulos antigos e novos, contratos estáveis e disciplina de fronteira. Se seu time está exausto, com conhecimento concentrado em duas pessoas e sem espaço para absorver o impacto, a estratégia ideal pode ser começar com uma auditoria, uma camada de extração e uma squad sênior dedicada. Em alguns casos, isso vale mais do que contratar dezenas de pessoas e tentar resolver no volume.

Reescrever pode fazer sentido quando o produto está em um ponto de ruptura e a base atual bloqueia praticamente todas as próximas apostas. Isso costuma acontecer em sistemas muito antigos, sem testes confiáveis, com modelos de dados confusos e arquitetura tão misturada que qualquer extração vira uma cirurgia de alto risco. Nesses cenários, tentar “consertar por dentro” pode sair mais caro do que começar uma base nova, desde que haja disciplina para não repetir os mesmos erros. O risco da reescrita total é conhecido, mas frequentemente subestimado. Ela costuma alongar prazo, consumir foco da liderança e criar a ilusão de progresso porque o time “está construindo”, embora o mercado ainda não veja valor novo. Uma reescrita mal conduzida também pode congelar aprendizado, já que a empresa deixa de iterar no produto vivo e passa a apostar em um grande lançamento. Para CTOs e CEOs, isso precisa ser tratado como um programa de risco, não como um projeto de engenharia. Há ainda o risco de trocar um problema ruim por outro igual. Sem discovery, sem tech audit e sem critérios de corte, a equipe corre o perigo de reproduzir no novo stack as mesmas dependências, acoplamentos e decisões apressadas. É por isso que uma reescrita madura quase sempre começa com recorte de escopo, definição de domínio e plano de convivência com o sistema antigo. Se o seu contexto envolve dados, IA ou integrações críticas, combine essa leitura com o guia de observabilidade para produtos digitais com IA para que a nova base nasça com métricas, tracing e custo visíveis desde o início. Em termos de estratégia, reescrever é mais defensável quando o negócio pode suportar uma janela maior de investimento e quando o sistema atual já não permite evolução incremental segura. Em empresas sob pressão comercial, com time pequeno e clientes ativos, a reescrita total sem transição costuma ser um erro de gestão, não de tecnologia.

O padrão strangler funciona bem quando o produto já gera receita, tem usuários ativos e não pode parar para uma reconstrução longa. A lógica é simples: você cria uma nova camada ou novos serviços ao redor do monolito, migra capacidades aos poucos e desativa o legado conforme cada parte amadurece. Isso reduz risco porque cada migração é uma aposta pequena, com validação prática em produção. Na prática, essa abordagem permite preservar o que já funciona enquanto você corrige os gargalos que estão travando a expansão. Em vez de reescrever o produto inteiro, você extrai domínios com maior dor, como processamento de pagamentos, emissão de documentos, motor de regras ou integrações com sistemas corporativos. Para times que lidam com múltiplos clientes e requisitos de governança, essa estratégia tende a ser mais compatível com continuidade operacional. Ela também ajuda a manter o roadmap comercial vivo. Quando o time consegue entregar melhorias em paralelo à modernização da base, o CEO não precisa escolher entre vender e evoluir a tecnologia. Esse tipo de transição é comum em projetos enterprise, inclusive em cenários que exigem integrações com plataformas como AWS, Azure, GCP, Power BI e SAP. Se a sua discussão inclui reorganização de time, o playbook de feature teams ajuda a garantir que a arquitetura nova não fique refém da estrutura antiga. Estrangular, porém, não é sinônimo de fazer devagar. É uma migração disciplinada, com sequência clara, métricas e critérios de saída. Sem isso, o monolito continua crescendo enquanto a “modernização” fica pela metade.

O erro número um é transformar uma decisão de negócio em uma disputa de ego entre áreas. Quando o CEO quer velocidade e o CTO quer preservar sustentabilidade, a empresa precisa de um diagnóstico compartilhado, não de um vencedor. Em projetos grandes, essa tensão é estrutural. Ignorá-la só faz o problema aparecer mais tarde, com atraso de entrega, retrabalho e ruído político. O segundo erro é começar pelo componente mais visível, e não pelo mais valioso. Trocar a interface ou reescrever a stack de ponta sem resolver os fluxos críticos costuma gerar uma sensação falsa de avanço. Em geral, a maior alavanca está em domínio, integração, observabilidade e fluxo de entrega, não em estética de arquitetura. Quem quer base sólida precisa pensar em comportamento do sistema, não só em organização de código. O terceiro erro é subestimar governança e transição de conhecimento. Toda modernização séria precisa de documentação viva, critérios de aceitação, acordos de operação e desenho de saída para que o time interno não fique dependente do fornecedor. Essa disciplina é ainda mais relevante quando há equipes alocadas, pois o objetivo não é criar uma caixa-preta, e sim acelerar sem perder autonomia. Se esse é o seu cenário, vale olhar também a governança prática para equipes alocadas e o contrato de saída e code escrow para squads alocados. O quarto erro é prometer números absolutos antes de medir a realidade. Cada sistema tem um nível diferente de acoplamento, qualidade de testes, latência, criticidade e maturidade de processo. Por isso, a decisão correta vem depois de um audit sério, não depois de um slide bonito.