Resumo
Este artigo apresenta uma análise técnica da arquitetura monolÃtica no desenvolvimento de software, abordando seus fundamentos, variações, vantagens e limitações. Discute-se o monolito tradicional, o monolito modular e o monolito distribuÃdo, além de cenários reais de empresas como Shopify, Stack Overflow, Basecamp e Istio. Conclui-se que, apesar do apelo contemporâneo dos microsserviços, o monolito permanece uma escolha arquitetural legÃtima e, em muitos casos, preferÃvel.
Introdução
Nos últimos dez anos, o discurso dominante na engenharia de software elegeu os microsserviços como sinônimo de modernidade, relegando a arquitetura monolÃtica ao papel de "legado" indesejável. Essa associação, contudo, é imprecisa e prejudicial à tomada de decisão técnica. Como observa Newman (2020), "o termo 'monolito' tornou-se um substituto para a palavra 'legado', e isso é inadequado, pois um monolito se refere, na verdade, à unidade de implantação".
Este artigo propõe uma leitura técnica da arquitetura monolÃtica. A relevância da discussão é prática: a maioria das aplicações web em operação no mundo ainda é monolÃtica, e casos recentes como a consolidação do control plane do Istio em 2020(BOX, 2020) e a redução de 90% de custos do Prime Video ao migrar componentes serverless para um monolito em contêineres (KOLNY, 2023) mostram que o padrão segue estrategicamente vivo. Compreendê-lo em profundidade é, portanto, pré-requisito para qualquer decisão arquitetural consciente.
Definição e caracterÃsticas
Lewis e Fowler (2014) definem o monolito como "uma aplicação servidor única, um executável lógico único, em que qualquer alteração no sistema envolve construir e implantar uma nova versão da aplicação". A caracterÃstica definidora, segundo Newman (2020), é a unidade única de implantação: todo o código precisa ser empacotado, testado e publicado em conjunto. Desse atributo derivam as demais propriedades do estilo: código-base único, comunicação in-process por chamadas de função, memória compartilhada, pipeline único de build e, tipicamente, um banco de dados unificado.
Martin (2019, p. 162) lembra que essa configuração oferece um benefÃcio técnico concreto: "as comunicações entre componentes em um monolito são muito rápidas e baratas", diferentemente de arquiteturas distribuÃdas, nas quais chamadas de rede introduzem latência, falhas parciais e complexidade de orquestração.
Tipos de monolito
Newman (2020) distingue três variações relevantes. O monolito de processo único (single-process monolith) é a forma clássica: todo o código roda em um único processo, geralmente contra um banco de dados compartilhado. O monolito modular é, nas palavras do autor, "um único processo composto por módulos separados, cada um podendo ser trabalhado de forma independente, mas combinados para o deploy". Já o monolito distribuÃdo é considerado antipadrão, "um sistema composto por múltiplos serviços que, por alguma razão, precisam ser implantados juntos", acumulando desvantagens dos dois mundos.
Richards e Ford (2020) complementam com o monolito em camadas (layered architecture), no qual o código é organizado horizontalmente em camadas de apresentação, negócio, persistência e dados, de modo que "mudanças feitas em uma camada geralmente não impactam componentes das outras camadas".
Vantagens
A principal vantagem do monolito é a simplicidade operacional. Como descreve Westeinde (2019), engenheira do Shopify, "manter todo o código em um só lugar e implantar em um único destino traz muitas vantagens: um único repositório, um único pipeline de testes e deploy, e um único banco compartilhado". Também há a performance das chamadas locais, a facilidade de testes de ponta a ponta, o stack trace único para depuração e o custo reduzido de infraestrutura.
Heinemeier Hansson (2016), criador do Ruby on Rails, sintetiza o argumento filosófico: "o problema de transformar prematuramente sua aplicação em uma série de serviços é violar a regra nº 1 da computação distribuÃda: não distribua sua computação".
Desvantagens
A escalabilidade é limitada à replicação vertical ou à cópia integral de instâncias, impossibilitando escalar funcionalidades de forma independente. Sem disciplina arquitetural, o acoplamento entre módulos tende a crescer: o Shopify relatou que, antes da modularização, "a aplicação era extremamente frágil, e mudanças aparentemente inofensivas disparavam cascatas de falhas em testes não relacionados" (WESTEINDE, 2019). Há ainda a rigidez tecnológica (uma única stack para toda a aplicação), o risco associado a deploys amplos e a crescente lentidão de build em bases muito grandes.
Quando adotar o monolito
Fowler (2015) propõe o princÃpio Monolith First: "quase todas as histórias de sucesso em microsserviços começaram com um monolito que ficou grande demais e foi particionado; quase todos os casos em que ouvi falar de sistemas construÃdos como microsserviços desde o inÃcio acabaram em sérios problemas". A justificativa é a dificuldade de estabelecer bons bounded contexts antes de se conhecer o domÃnio. Produtos em validação, MVPs, startups e equipes pequenas costumam obter melhor relação custo-benefÃcio com monolitos.
Os casos práticos corroboram esse raciocÃnio. O Shopify mantém um monolito Ruby on Rails com mais de 2,8 milhões de linhas e mais de mil desenvolvedores ativos (WESTEINDE, 2019). O Stack Overflow serve cerca de 209 milhões de requisições diárias com uma aplicação ASP.NET monolÃtica (CRAVER, 2016). O Segment, após migrar para 250 microsserviços, reverteu para uma arquitetura unificada e ampliou sua velocidade de entrega(NOONAN, 2018). Tais exemplos não invalidam os microsserviços, mas demonstram que o monolito, quando bem projetado, é uma arquitetura contemporânea e competitiva.
Considerações finais
A arquitetura monolÃtica não é obsoleta, tampouco inferior por natureza. É um estilo arquitetural com trade-offs próprios que, em muitos contextos, oferece a melhor combinação de simplicidade, performance e custo. A tendência contemporânea do monolito modular, fundamentada em Domain-Driven Design e na delimitação explÃcita de fronteiras, aponta para um caminho equilibrado: manter os ganhos operacionais do monolito enquanto se preservam a coesão interna e a possibilidade de evolução futura para microsserviços, quando e se forem justificados. A lição central, sintetizada por Tilkov (2015), permanece oportuna: "se você não consegue construir um monolito bem estruturado, o que o faz pensar que conseguirá construir um bom conjunto de microsserviços?".
Referências
BOX, C. Introducing istiod: simplifying the control plane. Istio Blog, 19 mar. 2020. DisponÃvel em: https://istio.io/latest/blog/2020/istiod/. Acesso em: 18 abr. 2026.
CRAVER, N. Stack Overflow: The Architecture – 2016 Edition. Nick Craver Blog, 17 fev. 2016. DisponÃvel em: https://nickcraver.com/blog/2016/02/17/stack-overflow-the-architecture-2016-edition/. Acesso em: 18 abr. 2026.
FOWLER, M. MonolithFirst. martinfowler.com, 3 jun. 2015. DisponÃvel em: https://martinfowler.com/bliki/MonolithFirst.html. Acesso em: 18 abr. 2026.
HEINEMEIER HANSSON, D. The Majestic Monolith. Signal v. Noise, 29 fev. 2016. DisponÃvel em: https://signalvnoise.com/svn3/the-majestic-monolith/. Acesso em: 18 abr. 2026.
KOLNY, M. Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%. Prime Video Tech Blog, maio 2023. DisponÃvel em: https://www.primevideotech.com/video-streaming/scaling-up-the-prime-video-audio-video-monitoring-service-and-reducing-costs-by-90. Acesso em: 18 abr. 2026.
LEWIS, J.; FOWLER, M. Microservices: a definition of this new architectural term. martinfowler.com, 25 mar. 2014. DisponÃvel em: https://martinfowler.com/articles/microservices.html. Acesso em: 18 abr. 2026.
MARTIN, R. C. Arquitetura Limpa: o guia do artesão para estrutura e design de software. Rio de Janeiro: Alta Books, 2019.
NEWMAN, S. Building Microservices: Designing Fine-Grained Systems. 2. ed. Sebastopol: O'Reilly Media, 2021.
NEWMAN, S. Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith. Sebastopol: O'Reilly Media, 2020.
NOONAN, A. Goodbye Microservices: From 100s of problem children to 1 superstar. Segment Blog, 10 jul. 2018. DisponÃvel em: https://segment.com/blog/goodbye-microservices/. Acesso em: 18 abr. 2026.
RICHARDS, M.; FORD, N. Fundamentos de Arquitetura de Software: uma abordagem de engenharia. Porto Alegre: Bookman, 2021.
TILKOV, S. Don't Start with a Monolith. martinfowler.com, 9 jun. 2015. DisponÃvel em: https://martinfowler.com/articles/dont-start-monolith.html. Acesso em: 18 abr. 2026.
WESTEINDE, K. Deconstructing the Monolith: Designing Software that Maximizes Developer Productivity. Shopify Engineering, 21 fev. 2019. DisponÃvel em: https://shopify.engineering/deconstructing-monolith-designing-software-maximizes-developer-productivity. Acesso em: 18 abr. 2026.
