Este artigo estuda o uso da arquitetura monolítica no contexto do desenvolvimento de software moderno. Frequentemente comparada com microserviços, a arquitetura monolítica apresenta aspectos positivos e negativos quanto à sua confiabilidade e usabilidade. O texto aborda suas características, prós e contras, o papel das APIs REST na comunicação interna e externa, e os critérios para a escolha desse modelo arquitetural.
Introdução
A escolha da arquitetura no início de um projeto é uma das decisões mais críticas do desenvolvimento, com impacto direto na produtividade da equipe e na capacidade de escalar o sistema. Durante muito tempo, a migração para microserviços foi tratada pela indústria como um passo natural e quase obrigatório para qualquer aplicação com pretensão de crescimento. Essa visão começou a ser questionada por profissionais experientes da área, que passaram a apontar a complexidade desnecessária que os microserviços impõem — especialmente em estágios iniciais — e a defender a solidez da arquitetura monolítica quando bem aplicada.
Este artigo defende que o monolito, quando estruturado com cuidado, continua sendo a escolha mais eficiente para a maioria dos sistemas. O argumento se apoia na teoria de Chris Richardson e Martin Fowler sobre padrões arquiteturais, na experiência prática da Shopify com o monolito modular, e na visão de David Heinemeier Hansson (DHH) sobre os custos reais de distribuir um sistema antes da hora.
Fundamentação Teórica
O conceito da Arquitetura Monolítica
Uma aplicação monolítica é construída como uma única unidade lógica: a lógica de negócio, o acesso a dados e a interface residem no mesmo processo. Segundo Richardson, esse modelo é simples de desenvolver, testar e colocar em produção, já que envolve apenas uma unidade de deploy — seja um arquivo JAR ou a estrutura de diretórios de um projeto Rails.
O problema aparece quando o sistema cresce sem controle. A ausência de fronteiras claras vai tornando o código cada vez mais frágil e arriscado de modificar — situação conhecida como "Inferno Monolítico". É nesse ponto que entra o conceito de Monolito Modular, discutido por DHH no artigo "The Majestic Monolith" (HANSSON, 2016).
O monolito Majestoso e a Modularizção
DHH cunhou o termo "Monolito Majestoso" para nomear sistemas integrados que resistem à abstração desnecessária. O argumento central é que distribuir um sistema traz problemas de rede e de consistência de dados que, para equipes pequenas ou médias, tendem a custar mais do que os benefícios que oferecem (HANSSON, 2016).
O caso da Shopify é um bom exemplo disso na prática. Quando o monolito Ruby on Rails da empresa começou a mostrar seus limites, a equipe decidiu não fragmentar o sistema em serviços independentes. Em vez disso, apostaram na Componentização: reorganizar o código em torno de conceitos reais de negócio, como pagamentos e logística, forçando fronteiras por meio de APIs internas sem abrir mão do repositório e do banco de dados únicos. Para acompanhar esse processo, a Shopify criou internamente uma ferramenta chamada Wedge, que rastreava o grau de isolamento de cada componente e sinalizava violações de fronteira durante a integração contínua (WESTEINDE, 2019).
O papel da API REST na arquitetura
Mesmo dentro de um monolito, o padrão REST é relevante. Num monolito modular, as APIs REST não servem só para o front-end — elas podem funcionar como contratos entre componentes internos, tornando as fronteiras de domínio explícitas e facilitando uma eventual extração de módulos no futuro. É o que Fowler chama de preparação para os MicroservicePrerequisites: uma API interna bem definida hoje é a saída mais organizada para microserviços amanhã, se esse dia chegar (FOWLER, 2015).
Comparações e Trade-offs
A vantagem mais direta do monolito sobre microserviços é operacional: sem chamadas de rede entre serviços, não há latência adicional nem pontos extras de falha. Fowler defende que, na maioria dos casos, faz mais sentido começar com um monolito — refatorar código dentro de um sistema único é muito mais simples do que mover funcionalidades entre serviços já em produção. Microserviços demandam maturidade de infraestrutura e cultura de monitoramento que só se justificam quando a complexidade do negócio torna o monolito genuinamente insustentável (FOWLER, 2015).
Fowler não está defendendo o monolito como solução permanente — está defendendo o momento certo de cada decisão. Praticamente todos os casos bem-sucedidos de microserviços começaram com um monolito que cresceu a ponto de precisar ser dividido. Os sistemas que nasceram como microserviços, por outro lado, costumam enfrentar dificuldades sérias. Dentro de um sistema único é muito mais fácil descobrir onde as fronteiras de domínio realmente ficam do que tentar adivinhar isso antes de ter qualquer experiência com o negócio (FOWLER, 2015).
Conclusão
Tratar a arquitetura monolítica como um estágio ultrapassado ignora tanto a teoria quanto casos concretos da indústria. A Shopify optou por evoluir seu monolito em vez de abandoná-lo. DHH mantém o Basecamp como monolito há mais de vinte anos, atendendo milhões de usuários com uma equipe pequena. Fowler recomenda explicitamente o monolito como ponto de partida para qualquer novo projeto.
A decisão arquitetural deveria partir do contexto real: tamanho da equipe, maturidade do domínio de negócio e sinais concretos de que a estrutura atual está travando o desenvolvimento. Para a maior parte dos sistemas, o monolito — especialmente quando modularizado com disciplina — continua sendo a escolha mais sustentável.
Este artigo foi feito com o auxílio de Tiago Fritzen Palácio para fins didáticos.
Referências
FOWLER, Martin. MonolithFirst. martinfowler.com, 3 jun. 2015. Disponível em: https://martinfowler.com/bliki/MonolithFirst.html. Acesso em: abr. 2026.
HANSSON, David Heinemeier. The Majestic Monolith. Signal v. Noise, 29 fev. 2016. Disponível em: https://signalvnoise.com/svn3/the-majestic-monolith/. Acesso em: abr. 2026.
WESTEINDE, Kirsten. Deconstructing the Monolith: Designing Software that Maximizes Developer Productivity. Shopify Engineering Blog, 21 fev. 2019. Disponível em: https://shopify.engineering/deconstructing-monolith-designing-software-maximizes-developer-productivity. Acesso em: abr. 2026.
HARRIS, Chandler. Microsserviços versus arquitetura monolítica. Atlassian. Disponível em: https://www.atlassian.com/br/microservices/microservices-architecture/microservices-vs-monolith. Acesso em: abr. 2026.
Top comments (0)