Monólitos modulares estão substituindo microsserviços em equipas de engenharia de média dimensão

Durante a maior parte da última década, dividir uma aplicação em microsserviços era visto como a decisão responsável, aquela que se tomava quando a escala passava a importar de verdade. Em 2026, um número crescente de equipas de engenharia está a reverter silenciosamente essa decisão, não abandonando as fronteiras de serviço, mas reagrupando-as numa única unidade implantável com separação interna rigorosa: o monólito modular.

O exemplo público mais claro continua a ser a equipa Prime Video da Amazon, que em 2023 moveu o seu serviço de análise de qualidade de vídeo de um pipeline distribuído baseado em Lambda e microsserviços para um único processo monolítico. A equipa relatou uma redução de custos de infraestrutura de cerca de 90% para esse serviço específico, além de uma depuração muito mais simples.

Por que o pêndulo voltou atrás

Os microsserviços resolvem um problema específico: capacidade de implantação e escalonamento independentes para equipas grandes o suficiente para que uma base de código partilhada se torne um ponto de estrangulamento de coordenação. Para uma organização de engenharia de 200 pessoas dividida em dezenas de equipas autónomas, essa compensação faz sentido. Mas para uma equipa de 15 pessoas a executar 40 microsserviços, a sobrecarga operacional consome o benefício suposto.

A Basecamp e a Shopify descreveram publicamente permanecer num, ou voltar a um, modelo de «monólito majestoso» em vez de se dividirem em dezenas de serviços, citando o mesmo raciocínio: a maioria dos seus caminhos de pedido não precisa de escalonamento independente.

Como é realmente um monólito modular

Um monólito modular não é «desistir e escrever código espaguete num único ficheiro». É uma única aplicação implantável organizada internamente em pacotes ou módulos com fronteiras explícitas e aplicadas, normalmente um módulo por domínio de negócio (faturação, inventário, notificações). Cada módulo possui a sua própria camada de acesso a dados e expõe uma interface interna estreita a outros módulos.

Isto proporciona a maioria dos benefícios que as pessoas originalmente queriam dos microsserviços, sem o imposto dos sistemas distribuídos: sem latência de rede entre módulos, sem tratamento de falhas parciais para chamadas que antes eram chamadas de função.

Quando os microsserviços ainda justificam o seu custo

O argumento honesto a favor dos microsserviços ainda existe. Se um componente precisar de escalar independentemente 50 vezes mais do que o resto do sistema, separá-lo é a decisão certa. A regra prática que surgiu entre as equipas em 2026: por defeito, opte por um monólito modular, e extraia um serviço apenas quando conseguir nomear o requisito específico de escalonamento, linguagem ou autonomia de equipa que o justifica.

Conclusões para equipas que reconsideram a sua arquitetura

Se a sua equipa tiver cerca de 50 engenheiros ou menos e executar mais do que um punhado de serviços, audite quais serviços realmente têm necessidades de escalonamento independentes face aos que foram divididos por razões organizacionais que já não se aplicam. Mantenha as fronteiras de módulo; elimine os saltos de rede.