Há alguns anos, falar monólitos era quase um palavrão no mundo tech. Todo mundo queria microsserviços. Cada função virava um serviço independente, cada time tinha seu próprio repositório, e a complexidade, bem, essa ficava pra depois resolver.

Só que “depois” chegou.

Empresas grandes e pequenas começaram a perceber que o sonho dos microsserviços tinha um custo alto: infraestrutura cara, debugging complicado e times travados esperando outros times. E foi aí que o pêndulo começou a balançar de volta.

Hoje, o retorno aos monólitos não é nostalgia, é estratégia. DHH, criador do Ruby on Rails, voltou atrás com o Basecamp. A Amazon publicou um case mostrando como simplificou seu sistema ao abandonar microsserviços. O Shopify ainda roda num monólito gigante. E não é por falta de capacidade técnica.

A questão central é: quando a complexidade adicional realmente vale o custo? Para a maioria dos projetos e times, a resposta honesta é “quase nunca”. E reconhecer isso não é fraqueza, é engenharia de verdade.

Neste artigo, você vai entender por que esse movimento está acontecendo, quando faz sentido adotar essa abordagem e, principalmente, como usar APIs externas para ter o melhor dos dois mundos sem abrir mão da simplicidade.

Microsserviços: A promessa e a conta que chegou

Durante anos, a narrativa foi clara: microsserviços = modernidade. Monólitos = legado. A lógica parecia sólida, serviços independentes, deploys isolados, escalabilidade granular.

Mas a realidade no dia a dia de desenvolvimento mostrou outro cenário.

Vale lembrar que a adoção de microsserviços foi, em muitos casos, impulsionada por decisões de cima para baixo — gestores que leram artigos sobre Netflix e Google e quiseram o mesmo para sistemas com uma fração do tráfego. O resultado foi arquitetura de empresa de bilhões de usuários aplicada a produtos com milhares. O desalinhamento entre complexidade e escala real gerou uma crise silenciosa que demorou anos para aparecer nos relatórios.

O que ninguém contava no começo

Sistemas distribuídos trazem uma categoria inteira de problemas que simplesmente não existem num monólito:

• Latência de rede entre serviços: Uma operação que seria uma chamada de função local vira uma requisição HTTP com timeout, retry e possível falha parcial.
• Debugging fragmentado: Um erro numa jornada de usuário pode atravessar 6, 8, 10 serviços. Rastrear isso exige ferramentas de observabilidade caras e complexas.
• Overhead operacional: Cada serviço precisa de deploy pipeline, configuração, monitoramento e — muitas vezes — um time responsável.
• Consistência de dados: Transações distribuídas são um pesadelo. O que era um BEGIN TRANSACTION simples vira saga, event sourcing, compensação…

Aspecto	Microsserviços	Monólito Moderno
Complexidade operacional	Alta — múltiplos deploys	Baixa — um deploy só
Debug de erros	Difícil — rastreio entre serviços	Simples — stack trace local
Custo de infraestrutura	Alto — N servidores/containers	Menor — instâncias consolidadas
Onboarding de novos devs	Lento — muitos repositórios	Rápido — contexto centralizado
Escalabilidade granular	Sim, por serviço	Limitada (mas melhorável com APIs)
Latência interna	Alta — rede entre serviços	Baixa — chamadas em memória

O problema raramente é a arquitetura em si, é a complexidade prematura. A maioria dos sistemas não atinge o volume que justifica microsserviços. Começar simples e evoluir conforme a necessidade é uma estratégia sólida e cada vez mais defendida por engenheiros seniores.

Portanto, antes de dividir seu sistema em 30 serviços, vale perguntar: você realmente precisa de escala independente em cada parte? Na maioria dos casos, a resposta honesta é não.

O Movimento de retorno: Quem está liderando?

O debate saiu das conversas de corredor e virou pauta em conferências, posts de engenharia e decisões públicas de empresas relevantes. Então, os monólitos não estão voltando porque são moda, estão voltando porque funcionam.

Cases reais que mudaram a conversa

Amazon Prime Video publicou, em 2023, um artigo técnico descrevendo como migrou seu serviço de monitoramento de vídeo de uma arquitetura serverless/microsserviços para um monólito. O resultado? Redução de 90% nos custos de infraestrutura e simplificação drástica do sistema.

Shopify mantém até hoje um dos maiores monólitos Ruby on Rails em produção. Com bilhões em transações processadas, eles continuam apostando na arquitetura unificada, com otimizações cirúrgicas onde necessário.

Stack Overflow é outro exemplo clássico: uma das maiores comunidades de dev do mundo rodando em poucos servidores, com uma arquitetura relativamente simples.

Isso não significa que microsserviços são errados. Significa que eles têm um custo real de complexidade que precisa ser justificado pela escala e necessidade do negócio. Adotar microsserviços “porque é o que se faz hoje” sem essa justificativa é um dos erros mais caros que um time pode cometer.

O que mudou na percepção da comunidade

Alguns fatores aceleraram essa revisão de postura:

• Hardware ficou mais poderoso e barato. Um servidor moderno consegue escalar muito mais do que antes — o argumento “precisamos de microsserviços pra escalar” perdeu força.
• Ferramentas de deploy melhoraram. Blue-green deployment, feature flags e zero-downtime deploys tornaram o ciclo de release de um monólito muito mais ágil.
• Observabilidade interna avançou. Profilers modernos e APMs tornam o monólito mais transparente do que era há 10 anos.
• O débito técnico de microsserviços ficou evidente. Times que adotaram a arquitetura distribuída cedo estão colhendo — literalmente — os frutos do débito técnico acumulado.

Quando usar Monólito (e quando não usar)

Entender o contexto certo para cada abordagem é o que diferencia um engenheiro sênior de alguém que só segue tendências. Os monólitos não são a resposta para tudo, mas são a resposta certa com muito mais frequência do que o mercado admitia.

Cenários onde o monólito ganha

• Times pequenos (até ~10-15 engenheiros): A sobrecarga operacional de microsserviços consome tempo que times pequenos simplesmente não têm.
• Produtos em fase inicial: Quando o domínio ainda está sendo descoberto, dividir prematuramente cria barreiras para refatorar.
• Aplicações com domínio coeso: Se as funcionalidades estão fortemente relacionadas, separá-las traz mais acoplamento do que independência.
• Projetos com orçamento limitado de infra: Manter N serviços rodando 24/7 custa muito mais do que um processo bem otimizado.

O que “monólito ruim” realmente significa

Existe um equívoco comum: quando alguém fala “monólito legado problemático”, geralmente está descrevendo um Big Ball of Mud — código sem organização, sem separação de responsabilidades, sem testes. Isso não é um problema da arquitetura monolítica. É um problema de qualidade de código.

Um monólito bem estruturado tem módulos bem definidos, separação clara de domínios, testes automatizados e convenções arquiteturais respeitadas. A diferença entre um monólito saudável e um problemático não é a arquitetura — é a disciplina do time.

O modelo híbrido que está funcionando

Uma abordagem que vem ganhando força é o “monólito modular”: uma base unificada, com separação clara de domínios internamente, e uso estratégico de APIs externas para funcionalidades específicas.

Funcionalidades como validação de CPF, consulta de CNPJ e busca de CEP são exemplos perfeitos de casos onde não faz sentido construir e manter internamente. Você consome via API, mantém seu sistema limpo e ainda ganha confiabilidade.

APIs externas: O complemento perfeito para Monólitos modernos

Aqui está uma virada de chave importante: o retorno aos monólitos não significa fechar a porta para o mundo externo. Pelo contrário, significa ser mais estratégico sobre o que você constrói vs. o que você consome.

O princípio “não reinvente a roda”

Os times de desenvolvimento têm um recurso finito e valioso: o tempo de engenharia. Cada hora gasta construindo e mantendo uma integração com a Receita Federal para consultar CNPJ é uma hora a menos em features que realmente diferenciam seu produto.

APIs de dados públicos — como CPF, CNPJ e CEP — são casos clássicos de funcionalidades que:

• Já existem como infraestrutura confiável no mercado
• Precisam de manutenção constante quando construídas internamente (mudanças de formato, instabilidades, atualização de dados)
• Têm custo de erro alto — um CNPJ validado errado pode criar problemas legais e operacionais
• São periféricas ao core do produto — elas suportam, mas não definem o negócio

Times que substituem integrações próprias com a Receita Federal por APIs especializadas relatam redução de até 60% no tempo de manutenção dessas funcionalidades — tempo que vai direto para desenvolvimento de produto.

Documentação e experiência do desenvolvedor importam

Outro ponto que muitos times ignoram na hora de avaliar APIs externas: a qualidade da documentação e do suporte. Uma API barata com documentação ruim pode custar muito mais em horas de engenharia tentando descobrir como ela funciona.

Ao avaliar uma API externa para integrar ao seu monólito, considere:

• Tempo de resposta médio: latência alta impacta diretamente a experiência do usuário final
• Uptime e SLA: uma API que cai te derruba junto — verifique o histórico de disponibilidade
• Clareza da documentação: você consegue fazer a primeira chamada em menos de 10 minutos?
• Suporte responsivo: tem canal de comunicação real quando algo quebra?
• Custo por requisição: calcule o custo real no volume que você precisa — surpresas na fatura são comuns

Como o Hub do Desenvolvedor encaixa nessa arquitetura

O Hub do Desenvolvedor oferece APIs prontas para consulta de CPF, CNPJ e CEP, exatamente o tipo de funcionalidade que faz mais sentido consumir do que construir.

Numa arquitetura monolítica moderna, a integração é direta:

• Uma chamada HTTP simples a partir do seu monólito
• Resposta estruturada em JSON, pronta pra usar
• Sem necessidade de manter scraping, parser ou integração direta com fontes governamentais
• Documentação clara e suporte técnico disponível

Ou seja: você mantém seu sistema simples e coeso — sem precisar virar um especialista em dados cadastrais brasileiros.

Monólitos: Como migrar de volta?

Decidiu que faz sentido consolidar? Ótimo — mas a migração precisa de estratégia. Simplesmente “juntar tudo” sem planejamento pode criar um monólito que carrega todos os problemas dos microsserviços, mais os problemas clássicos de sistemas mal estruturados.

O processo que funciona

Para executar essa mudança com sucesso, a abordagem mais segura é a migração incremental. Essa estratégia é frequentemente chamada de Strangler Fig Pattern reverso: ou seja, em vez de desmembrar um monólito em microsserviços, você consolida os microsserviços para formar um monólito robusto.

Como primeiro passo, mapeie detalhadamente as dependências reais; afinal, serviços com alta comunicação são candidatos óbvios à unificação. Em seguida, identifique aqueles com baixa frequência de mudança, visto que são os mais fáceis de fundir sem riscos.

Além disso, antes mesmo de unificar o código, comece pela infraestrutura compartilhada, como o banco de dados, autenticação e logging. Posteriormente, avance domínio por domínio, evitando fazer tudo de uma vez e garantindo sempre que cada etapa da consolidação seja testável e reversível.

Por fim, é crucial manter as APIs externas exatamente onde estão. Isso ocorre porque essa parte específica da arquitetura distribuída continua fazendo total sentido e, portanto, não precisa sofrer qualquer alteração.

Armadilhas comuns na migração

Durante projetos de consolidação arquitetural, alguns erros costumam aparecer repetidamente. Primeiramente, o equívoco de tentar migrar tudo de uma só vez eleva drasticamente o risco de quebrar o sistema em produção. Portanto, o caminho ideal é realizar a migração por partes, validando cuidadosamente cada etapa.

Em segundo lugar, é comum observar times que consolidam o código, mas acabam ignorando o banco de dados, mantendo-os separados. Contudo, essa abordagem traz apenas ganhos parciais, sendo essencial planejar também a unificação completa dos dados.

Além disso, não atualizar os processos da equipe é uma falha crítica. Afinal, se as esteiras de CI/CD, os rituais de deploy e as revisões não acompanharem a nova realidade, o monólito rapidamente acumulará os mesmos vícios do passado.

Por fim, a prática de consolidar sem refatorar deve ser evitada a todo custo, visto que simplesmente juntar código ruim não resulta em um software melhor. Em vez disso, aproveite a oportunidade da migração para organizar a base, eliminar o débito técnico e, sobretudo, estabelecer convenções claras.

O que preservar durante a migração

Embora a escolha arquitetural seja por um monólito, alguns elementos consagrados dos sistemas distribuídos ainda valem muito a pena ser mantidos.

Primeiramente, é fundamental garantir a separação lógica de domínios, mesmo que todos operem dentro do mesmo processo. Para que essa estrutura funcione adequadamente, deve-se estabelecer contratos claros, ou seja, interfaces muito bem definidas entre os diferentes módulos da aplicação.

Além disso, a adoção de testes de integração robustos torna-se indispensável para assegurar a estabilidade do sistema como um todo. Em paralelo, a implementação de feature flags é altamente recomendada, visto que permite um rollout gradual e controlado de novas mudanças, mitigando riscos no ambiente de produção.

Por fim, a delegação de responsabilidades complexas continua sendo uma decisão altamente estratégica. Sendo assim, manter o uso de APIs externas para lidar com dados especializados, como, por exemplo, consultas de CPF, CNPJ e CEP, é a melhor forma de enriquecer a aplicação sem que a sua equipe perca o foco naquilo que realmente importa: o core do negócio.

Conclusões sobre os Monólitos

Em essência, o retorno aos monólitos não representa um passo atrás, mas sim a consolidação da maturidade coletiva da indústria. Isso porque, após anos experimentando arquiteturas distribuídas em escalas desnecessárias, os times de engenharia compreenderam que complexidade não é sinônimo de qualidade. Afinal, a arquitetura ideal é aquela que permite entregar valor com eficiência, e não apenas a que ganha destaque em palestras de tecnologia.

Consequentemente, essa mudança de postura transforma a nossa visão sobre a terceirização de funcionalidades. Se o objetivo de um monólito bem projetado é focar exclusivamente no core do produto, então faz todo o sentido delegar tarefas secundárias para APIs especializadas. De fato, a escolha da arquitetura sempre dependerá do seu contexto específico. Ainda assim, na maioria dos casos, um monólito bem estruturado entrega mais valor e rapidez com menor custo operacional.

Portanto, o grande truque reside em saber exatamente o que construir internamente e o que consumir. Por exemplo,validações de CPF, CNPJ e CEP são cenários onde APIs externas são imbatíveis. Sendo assim, você não precisa dominar as bases da Receita Federal; basta integrar uma boa API para garantir segurança e focar no seu negócio.